<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><title>FACULTAD DE CIENCIA Y TECNOLOGÍA</title><meta name="generator" content="StarOffice/OpenOffice.org XSLT (http://xml.openoffice.org/sx2ml)" /><meta name="author" content="Emanuel Goette" /><meta name="created" content="2007-04-20T01:46:00" /><meta name="changedby" content="emanuel" /><meta name="changed" content="2011-03-24T17:23:56" /><base href="." /><style type="text/css">
	@page { size: 20.999cm 29.699cm; margin-top: 1.251cm; margin-bottom: 1.251cm; margin-left: 2cm; margin-right: 2cm }
	table { border-collapse:collapse; border-spacing:0; empty-cells:show }
	td, th { vertical-align:top; }
	h1, h2, h3, h4, h5, h6 { clear:both }
	ol, ul { padding:0; }
	* { margin:0; }
	*.fr1 { font-size:12pt; vertical-align:top; background-color:#ffffff; padding:0.026cm; border-style:none; }
	*.fr10 { font-size:12pt; vertical-align:top; }
	*.fr2 { font-size:12pt; vertical-align:top; }
	*.fr3 { font-size:12pt; vertical-align:top; padding:0.026cm; border-style:none; }
	*.fr4 { font-size:12pt; vertical-align:top; text-align:center; }
	*.fr5 { font-size:12pt; vertical-align:top; text-align:center; }
	*.fr6 { font-size:12pt; vertical-align:top; text-align:center; }
	*.fr7 { font-size:12pt; vertical-align:top; text-align:center; }
	*.fr8 { font-size:12pt; vertical-align:top; text-align:center; margin-left:0cm; margin-right:0cm; padding-left:0.28cm; padding-right:0.28cm; padding-top:0.153cm; padding-bottom:0.153cm; border-style:none; }
	*.fr9 { font-size:12pt; vertical-align:top; margin-left:0.319cm; margin-right:0.319cm; padding:0.026cm; border-style:none; }
	*.Frame { font-size:12pt; vertical-align:top; text-align:center; }
	*.gr1 { font-size:12pt; }
	*.gr10 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr11 { font-size:12pt; margin-left:0.319cm; margin-right:0.319cm; }
	*.gr12 { font-size:12pt; padding-top:0.229cm; padding-bottom:0.229cm; padding-left:0.441cm; padding-right:0.441cm; }
	*.gr13 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr2 { font-size:12pt; }
	*.gr3 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr4 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr5 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr6 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr7 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr8 { font-size:12pt; padding-top:0cm; padding-bottom:0cm; padding-left:0cm; padding-right:0cm; }
	*.gr9 { font-size:12pt; padding-top:0.229cm; padding-bottom:0.229cm; padding-left:0.441cm; padding-right:0.441cm; }
	*.Graphics { font-size:12pt; vertical-align:top; text-align:center; }
	*.OLE { font-size:12pt; vertical-align:top; text-align:center; }
	*.Caption { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-top:0.212cm; margin-bottom:0.212cm; font-style:italic; }
	*.Contents1 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; text-indent:0cm; }
	*.Contents2 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0.499cm; margin-right:0cm; text-indent:0cm; }
	*.Contents3 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0.998cm; margin-right:0cm; text-indent:0cm; }
	*.Endnote { font-family:'Times New Roman'; font-size:10pt; text-align:left ! important; margin-left:0.499cm; margin-right:0cm; text-indent:-0.499cm; }
	*.Footer { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.Footnote { font-family:'Times New Roman'; font-size:10pt; text-align:left ! important; }
	*.Framecontents { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.Header { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.Heading { font-family:'Albany AMT', Arial; font-size:14pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; }
	*.Heading1 { font-family:'Thorndale AMT'; font-size:24pt; text-align:center ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.Heading10 { font-family:'Albany AMT', Arial; font-size:75%; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.Heading2 { font-family:'Thorndale AMT'; font-size:18pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.Heading3 { font-family:'Thorndale AMT'; font-size:14pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.Index { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.List { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.Marginalia { font-family:Arial; font-size:10pt; text-align:justify ! important; margin-left:2cm; margin-right:2cm; margin-top:0cm; margin-bottom:0.212cm; line-height:100%; text-indent:0cm; background-color:transparent; }
	*.NormalArial { font-family:Arial; font-size:10pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0.494cm; margin-bottom:0.494cm; text-indent:1.27cm; }
	*.NormalWeb { font-family:Verdana; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0.494cm; margin-bottom:0.494cm; text-indent:1.27cm; }
	*.P1 { font-family:'Times New Roman'; font-size:12pt; text-align:center ! important; }
	*.P10 { font-family:Arial; font-size:13pt; text-align:left ! important; }
	*.P100 { font-family:'Thorndale AMT'; font-size:12pt; text-align:center ! important; }
	*.P101 { font-family:'Thorndale AMT'; font-size:24pt; text-align:center ! important; }
	*.P11 { font-family:'Times New Roman'; font-size:16pt; text-align:left ! important; text-decoration:underline; }
	*.P12 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.P13 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.P14 { font-family:'Bitstream Charter'; font-size:22pt; text-align:center ! important; }
	*.P15 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; background-color:#ffff00; }
	*.P16 { font-family:Arial; font-size:14pt; text-align:left ! important; margin-left:0.635cm; margin-right:0cm; text-indent:0cm; font-weight:bold; text-decoration:underline; }
	*.P17 { font-family:Arial; font-size:12pt; text-align:left ! important; margin-left:0.635cm; margin-right:0cm; text-indent:0cm; }
	*.P18 { font-family:'Times New Roman'; font-size:13pt; text-align:left ! important; margin-left:0.635cm; margin-right:0cm; text-indent:0cm; }
	*.P19 { font-family:Arial; font-size:14pt; text-align:left ! important; margin-left:0.635cm; margin-right:0cm; text-indent:0cm; font-weight:bold; text-decoration:underline; }
	*.P2 { font-family:'Times New Roman'; font-size:12pt; text-align:center ! important; }
	*.P20 { font-family:Arial; font-size:14pt; text-align:justify ! important; margin-top:0.212cm; margin-bottom:0.212cm; font-weight:bold; text-decoration:underline; }
	*.P21 { font-family:Arial; font-size:10pt; text-align:justify ! important; margin-top:0.212cm; margin-bottom:0.212cm; }
	*.P22 { font-family:Arial; font-size:10pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.212cm; margin-bottom:0.212cm; text-indent:1.27cm; color:#323232; }
	*.P23 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-top:0cm; margin-bottom:0.494cm; }
	*.P24 { font-family:'Times New Roman'; font-size:10pt; text-align:left ! important; }
	*.P25 { font-family:Arial; font-size:10pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.212cm; margin-bottom:0.212cm; text-indent:0cm; color:#323232; }
	*.P26 { font-family:Arial; font-size:14pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.212cm; margin-bottom:0.212cm; text-indent:0cm; font-weight:bold; text-decoration:underline; }
	*.P27 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; }
	*.P28 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; font-weight:bold; }
	*.P29 { font-family:Arial; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; font-weight:normal; }
	*.P3 { font-family:'Times New Roman'; font-size:12pt; text-align:center ! important; }
	*.P30 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.423cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; }
	*.P31 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.423cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; font-weight:bold; }
	*.P32 { font-family:Arial, sans-serif; font-size:9.55000019073486pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.423cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; color:#000000; font-style:normal; font-weight:normal; }
	*.P33 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.423cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; }
	*.P34 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; font-weight:bold; }
	*.P35 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P36 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P37 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; color:#000000; background-color:transparent; }
	*.P38 { font-family:Arial; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P39 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P4 { font-family:'Times New Roman'; font-size:12pt; text-align:center ! important; }
	*.P40 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; font-weight:normal; }
	*.P41 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P42 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P43 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; font-style:normal; font-weight:normal; }
	*.P44 { font-family:'Times New Roman'; font-size:10pt; text-align:left ! important; }
	*.P45 { font-family:'Times New Roman'; font-size:10pt; text-align:left ! important; }
	*.P46 { font-family:Arial; font-size:10pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0.212cm; margin-bottom:0.212cm; text-indent:1.249cm; color:#323232; }
	*.P47 { font-family:'Thorndale AMT'; font-size:14pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P48 { font-family:Arial; font-size:14pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P49 { font-family:'Thorndale AMT'; font-size:14pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P5 { font-family:Arial; font-size:14pt; text-align:left ! important; font-weight:bold; text-decoration:underline; }
	*.P50 { font-family:'Thorndale AMT'; font-size:24pt; text-align:center ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P51 { font-family:'Thorndale AMT'; font-size:18pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P52 { font-family:'Thorndale AMT'; font-size:18pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P53 { font-family:'Thorndale AMT'; font-size:18pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P54 { font-family:'Thorndale AMT'; font-size:18pt; text-align:left ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; background-color:#ffff00; }
	*.P55 { font-family:'Thorndale AMT'; font-size:24pt; text-align:center ! important; margin-top:0.423cm; margin-bottom:0.212cm; font-weight:bold; }
	*.P56 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; text-indent:0cm; }
	*.P57 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0.499cm; margin-right:0cm; text-indent:0cm; }
	*.P58 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0.998cm; margin-right:0cm; text-indent:0cm; }
	*.P59 { font-family:'Bitstream Charter'; font-size:22pt; text-align:center ! important; }
	*.P6 { font-family:Arial; font-size:14pt; text-align:left ! important; font-weight:bold; background-color:#ffff00; text-decoration:underline; }
	*.P60 { font-family:Arial; font-size:13pt; text-align:left ! important; }
	*.P61 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P62 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P63 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P64 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P65 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P66 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P67 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P68 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P69 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P7 { font-family:Arial; font-size:14pt; text-align:center ! important; }
	*.P70 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P71 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P72 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P73 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P74 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P75 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P76 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P77 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P78 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P79 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P8 { font-family:Arial; font-size:10pt; text-align:left ! important; }
	*.P80 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P81 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P82 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P83 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P84 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P85 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P86 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P87 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P88 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P89 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P9 { font-family:Arial; font-size:36pt; text-align:center ! important; }
	*.P90 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P91 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P92 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P93 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P94 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P95 { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P96 { font-family:Arial; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P97 { font-family:Arial; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P98 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.P99 { font-family:Arial; font-size:12pt; text-align:left ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:0cm; background-color:transparent; }
	*.Quotations { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-left:1cm; margin-right:1cm; margin-top:0cm; margin-bottom:0.499cm; text-indent:0cm; }
	*.Standard { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.Standarduser { font-family:'Times New Roman'; font-size:12pt; }
	*.TableContents { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; }
	*.TableHeading { font-family:'Times New Roman'; font-size:12pt; text-align:center ! important; font-weight:bold; }
	*.Textodeglobo { font-family:Tahoma; font-size:8pt; text-align:left ! important; }
	*.Textoindependiente2 { font-family:'Times New Roman'; font-size:12pt; text-align:left ! important; margin-top:0cm; margin-bottom:0.212cm; line-height:200%; }
	*.Textbody { font-family:Arial; font-size:12pt; text-align:justify ! important; margin-left:0cm; margin-right:0cm; margin-top:0cm; margin-bottom:0.212cm; line-height:150%; text-indent:1.499cm; background-color:transparent; }
	*.Sect1 { background-color:transparent; }
	*.Absatz-Standardschriftart { }
	*.BulletSymbols { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.Emphasis { font-style:italic; }
	*.EndnoteSymbol { vertical-align:sup; }
	*.Footnoteanchor { vertical-align:sup; }
	*.FootnoteReference { vertical-align:sup; }
	*.FootnoteSymbol { vertical-align:sup; }
	*.Fuentedepárrafopredeter { }
	*.Internetlink { color:#000080; text-decoration:underline; }
	*.NumberingSymbols { }
	*.PageNumber { }
	*.Refdenotaalpie { vertical-align:sup; }
	*.StrongEmphasis { font-weight:bold; }
	*.T1 { }
	*.T10 { font-weight:bold; }
	*.T11 { font-weight:bold; }
	*.T12 { font-weight:bold; }
	*.T13 { color:#323232; font-family:Arial; font-size:10pt; }
	*.T14 { color:#323232; font-family:Arial; }
	*.T15 { color:#323232; font-family:Arial; font-size:12pt; }
	*.T16 { color:#323232; font-size:12pt; font-weight:bold; }
	*.T17 { color:#323232; }
	*.T18 { color:#323232; background-color:transparent; }
	*.T19 { color:#323232; font-family:arial; font-size:12pt; }
	*.T2 { font-family:Arial; }
	*.T20 { font-size:10pt; }
	*.T21 { font-size:10pt; font-weight:bold; }
	*.T22 { font-size:10pt; font-style:italic; }
	*.T23 { background-color:#ffff00; }
	*.T24 { }
	*.T25 { color:#000000; }
	*.T26 { color:#000000; font-weight:bold; }
	*.T27 { color:#000000; background-color:transparent; }
	*.T28 { font-style:italic; }
	*.T29 { font-style:italic; }
	*.T3 { font-family:Arial; text-decoration:underline; }
	*.T30 { background-color:#ffffff; }
	*.T31 { font-style:normal; }
	*.T32 { font-style:normal; background-color:#ffffff; }
	*.T33 { font-family:Cheltenham-Book, 'Times New Roman'; font-size:9pt; }
	*.T34 { }
	*.T35 { color:#333333; background-color:#ffffff; }
	*.T36 { font-family:'Times New Roman'; }
	*.T37 { font-family:'Times New Roman'; font-weight:bold; }
	*.T38 { font-family:'Times New Roman'; font-style:italic; }
	*.T39 { font-family:'Times New Roman'; font-style:italic; }
	*.T4 { font-family:Arial; font-weight:bold; text-decoration:underline; }
	*.T40 { font-family:'Times New Roman'; }
	*.T41 { font-family:'Times New Roman'; font-weight:bold; }
	*.T42 { font-size:12pt; }
	*.T43 { }
	*.T44 { text-decoration:underline; }
	*.T45 { font-weight:bold; text-decoration:underline; }
	*.T46 { }
	*.T47 { font-size:12pt; font-weight:bold; }
	*.T48 { font-family:arial; font-size:12pt; }
	*.T49 { font-family:arial; font-size:12pt; }
	*.T5 { font-family:Arial; }
	*.T50 { }
	*.T51 { }
	*.T52 { }
	*.T53 { font-family:Arial; }
	*.T54 { font-family:Arial; font-size:12pt; }
	*.T55 { font-family:Arial; font-size:12pt; }
	*.T56 { background-color:transparent; }
	*.T57 { font-family:'Times New Roman'; font-size:9.55000019073486pt; font-style:normal; font-weight:bold; }
	*.T58 { font-family:'Times New Roman'; font-size:9.55000019073486pt; font-style:normal; font-weight:bold; background-color:transparent; }
	*.T59 { font-family:'Times New Roman'; font-size:9.55000019073486pt; font-style:normal; font-weight:normal; background-color:transparent; }
	*.T6 { font-family:Arial; }
	*.T60 { font-family:'Times New Roman'; font-size:9.55000019073486pt; font-style:italic; font-weight:normal; background-color:transparent; }
	*.T61 { font-family:'Times New Roman'; font-size:9.55000019073486pt; font-style:normal; font-weight:normal; background-color:transparent; }
	*.T62 { font-style:normal; font-weight:normal; }
	*.T63 { font-family:Arial, sans-serif; font-style:normal; background-color:transparent; }
	*.T64 { font-family:'Times New Roman'; font-size:12pt; }
	*.T65 { font-family:'Times New Roman'; font-size:10.5pt; }
	*.T66 { font-family:'Times New Roman'; font-size:10pt; }
	*.T67 { font-family:'Times New Roman'; font-size:9pt; }
	*.T7 { font-family:Arial; font-weight:bold; }
	*.T8 { }
	*.T9 { font-weight:bold; }
	*.WW8Num10z0 { font-family:'Times New Roman'; font-size:12pt; }
	*.WW8Num10z1 { font-family:'Courier New'; }
	*.WW8Num10z2 { font-family:Wingdings; }
	*.WW8Num11z0 { font-family:Symbol; }
	*.WW8Num11z1 { font-family:'Courier New'; }
	*.WW8Num11z2 { font-family:Wingdings; }
	*.WW8Num13z0 { font-family:Symbol; }
	*.WW8Num13z1 { font-family:'Courier New'; }
	*.WW8Num13z2 { font-family:Wingdings; }
	*.WW8Num14z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num14z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num14z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num15z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num15z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num15z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num16z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num16z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num16z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num17z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num17z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num17z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num19z0 { font-family:Symbol; font-size:9pt; }
	*.WW8Num1z0 { font-family:Symbol; }
	*.WW8Num1z1 { font-family:'Courier New'; }
	*.WW8Num1z2 { font-family:Wingdings; }
	*.WW8Num20z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num20z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num20z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num21z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num21z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num21z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num22z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num22z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num22z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW8Num27z0 { font-family:Symbol; }
	*.WW8Num28z0 { font-family:Symbol; font-size:12pt; }
	*.WW8Num2z0 { font-family:Arial; }
	*.WW8Num2z1 { font-family:'Courier New'; }
	*.WW8Num2z2 { font-family:Wingdings; }
	*.WW8Num2z3 { font-family:Symbol; }
	*.WW8Num3z0 { font-family:Arial; }
	*.WW8Num3z1 { font-family:'Courier New'; }
	*.WW8Num3z2 { font-family:Wingdings; }
	*.WW8Num3z3 { font-family:Symbol; }
	*.WW8Num4z0 { font-family:Symbol; }
	*.WW8Num4z1 { font-family:'Courier New'; }
	*.WW8Num4z2 { font-family:Wingdings; }
	*.WW8Num5z0 { font-family:Symbol; }
	*.WW8Num5z1 { font-family:'Courier New'; }
	*.WW8Num5z2 { font-family:Wingdings; }
	*.WW8Num6z0 { font-family:Symbol; }
	*.WW8Num6z1 { font-family:'Courier New'; }
	*.WW8Num6z2 { font-family:Wingdings; }
	*.WW8Num7z0 { font-family:Symbol; font-size:10pt; }
	*.WW8Num7z1 { font-family:'Courier New'; font-size:10pt; }
	*.WW8Num7z2 { font-family:Wingdings; font-size:10pt; }
	*.WW8Num8z0 { font-family:Symbol; }
	*.WW8Num8z1 { font-family:'Courier New'; }
	*.WW8Num8z2 { font-family:Wingdings; }
	*.WW8Num9z0 { font-family:Wingdings; font-size:9pt; }
	*.WW8Num9z1 { font-family:'Wingdings 2'; font-size:9pt; }
	*.WW8Num9z2 { font-family:StarSymbol, 'Arial Unicode MS'; font-size:9pt; }
	*.WW-Símbolodenotafinal { }
	</style></head><body dir="ltr"><p class="P59">FACULTAD DE CIENCIA Y TECNOLOGÍA </p><p class="P14">INGENIERÍA EN SISTEMAS DE INFORMACION </p><p class="P14">SEDE ORO VERDE </p><p class="P5"> </p><p class="P5"> </p><p class="P5"> </p><p class="P5"> </p><p class="P5"> </p><p class="P9">“Arquitectura Orientada a Servicios” </p><p class="P5"> </p><p class="P11"> </p><p class="P11"> </p><p class="P11"> </p><p class="P11"> </p><p class="P10"><span class="T44">Cátedra:</span> Proyecto</p><p class="P10"> </p><p class="P10"><span class="T44">Alumno</span><span class="T46">: </span></p><p class="P10"> </p><ul style="margin-left:1.25cm;"><li class="P60" style="margin-left:0cm;"><p class="P60" style="margin-left:0.25cm;">Emanuel Goette </p></li></ul><p class="P19">Integrante </p><p class="P16"> </p><p class="P16"> </p><p class="P18"><span class="T3">Nombre</span><span class="T5">:</span><span class="T6"> Emanuel Goette</span></p><p class="P18"><span class="T3">Dirección</span><span class="T6">: Los Colibríes 261 – Casa 3 – Oro Verde – Entre Ríos</span></p><p class="P18"><span class="T3">Teléfono</span><span class="T5">:</span><span class="T6"> 0343-154596803</span></p><p class="P18"><span class="T3">Email</span><span class="T5">:</span><span class="T6"> emanuelpeg@yahoo.com.ar </span></p><p class="P17"> </p><p class="P17"> </p><h1 class="P50"><a name="_C3_8Dndice" />Índice</h1><p class="P35"> </p><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Índice</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Anteproyecto</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Tema</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Introducción</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Problema</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Objetivos</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Generales: </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Específicos:  </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Justificación y Relevancia </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Factibilidad del estudio</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Marco Teórico</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Hipótesis</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Variables </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Temas comprendidos en el proyecto</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Técnicas e Instrumentos</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Introducción </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Desarrollo Teórico</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que es SOA?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Cuándo implementar SOA?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que define la Arquitectura SOA?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Servicios.</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Gobierno SOA</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Registro o repositorio</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>ESB (Enterprise Service Bus)</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Orquestación y Coreografía.</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>WS-CDL</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>BPM</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>BPEL</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>CEP (Complex Event Processing) y ESP (Event Stream Processing)</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>EAI (Enterprise Application Integration)</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Cómo se desarrolla sobre una arquitectura SOA?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>SCA</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Componente</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Vinculaciones</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>La composición</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Cables y promoción. </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Dominios </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Usando políticas</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>SDO (Service Data Objects)</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Resumen</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Caso de estudio : blog</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Por que elegir SOA para el desarrollo Web 2.0?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Porque optar por soluciones Open Sources?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que plataforma utilizar?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que herramientas necesitamos en nuestro desarrollo?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que implementación SCA utilizar?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que herramienta de registro utilizar?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>¿Que herramienta BPM utilizar?</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P57"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Desarrollo de arquitectura del Blog </td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Framework open source y gratuitos</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Conclusión</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P56"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Bibliografía</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Libros:</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Papers:</td></tr></table><table border="0" cellspacing="0" cellpadding="0" class="P58"><colgroup><col style="width: 16.999cm" /></colgroup><tr><td>Sitios Web:</td></tr></table><p class="P35"> </p><h1 class="P50"><a name="Anteproyecto" />Anteproyecto</h1><h2 class="Heading2"><a name="Tema" />Tema</h2><p class="P8"> </p><p class="Textbody"><span class="T47">“Implementación de Arquitecturas de Software Orientadas a Servicios en la Web 2.0, basada en herramientas Open Source</span><span class="FootnoteSymbol"><span class="T16" /></span><span class="T47">”</span></p><p class="P7"> </p><h2 class="Heading2"><a name="Introducci_C3_B3n" />Introducción</h2><p class="P46"> </p><p class="Textbody"><span class="T17">La necesidad de las empresas de integrar la información de clientes remotos con una interfaz rica, de desarrollos rápidos y baratos, de aplicaciones estables y la disminución de los costos de comunicación dio nacimiento a una nueva forma de ver las aplicaciones, conocida como SOA (Service Oriented Architecture). Este estilo arquitectónico concibe una aplicación como un conjunto de servicios, los cuales pueden ser consumidores de otros servicios</span><span class="T18">;</span><span class="T17"> de esta  forma se puede reutilizar un mismo servicio con varias aplicaciones. El usuario solo tiene una interfaz que consume servicios que forman parte del conjunto de funcionalidades de una aplicación. </span></p><p class="Textbody"><span class="T19">En muy pocos casos un sistema no esta integrado o no se comunica con otros sistemas. Un sistema normalmente necesita datos de otro sistema para poder realizar sus procesos diarios. Además es muy común que aplicaciones de una empresa superpongan su funcionamiento, ya que no existen límites bien marcados entre los diferentes componentes que conforman la organización. Los departamentos de TI</span><span class="FootnoteReference"><span class="T48" /></span><span class="T19"> han resuelto este problema con interfaces costosas que permiten </span><span class="T49">que estos sistemas se comuniquen, limitando su escalabilidad y flexibilidad.</span></p><p class="Textbody">Una respuesta a los problemas citados es una arquitectura flexible orientada a la comunicación, donde las funcionalidades están encapsuladas y son accesibles por todas las aplicaciones y que además presenta una interfaz estándar al consumidor de la funcionalidad. La implementación natural de estas características es el estilo arquitectónico orientado a servicios. </p><p class="Textbody">SOA es un estilo arquitectónico que puede ser implementado de varias formas, pero en la actualidad solo algunas se basan en estándares abiertos; estos son los Web Services (WS) SOAP o REST y OSGI. Los Servicios Web permiten que las aplicaciones compartan información y que además invoquen funciones de otras aplicaciones independientemente de cómo se hayan creado las aplicaciones, sea cuál sea el sistema operativo o la plataforma en que se ejecutan y cuáles, los dispositivos utilizados para obtener acceso a ellas. Aunque los Servicios Web son independientes entre sí, pueden vincularse y formar un grupo de colaboración para realizar una tarea determinada.</p><p class="Textbody">SOA es una arquitectura bastante madura con varios productos en el mercado, los cuales varios son Open Source y gratuitos. Open source significa que se distribuyen con el código fuente dando la libertad de distribuirlo, modificarlo y estudiarlo. Es interesante que un producto puede sea competitivo funcionando con tecnologías abiertas y que permitan tanta libertad. Implementar una arquitectura SOA Open Source trae consigo múltiples ventajas.  </p><p class="Textbody">        La Web experimentó un cambio drástico en los últimos años volcándose a sus usuarios, los cuales tomaron mayor protagonismo. La Web 2.0 es un término que acuña diferentes hechos que describen la nueva web:</p><ul style="margin-left:1.25cm;"><li class="P61" style="margin-left:0cm;"><p class="P61" style="margin-left:0.25cm;"><span class="T17">La web se </span><span class="T18">“socializó”.</span></p></li><li class="P61" style="margin-left:0cm;"><p class="P61" style="margin-left:0.25cm;">La web se hizo más interactiva. </p></li><li class="P61" style="margin-left:0cm;"><p class="P61" style="margin-left:0.25cm;">La web brinda ahora mayores canales de comunicación e interrelación. </p></li></ul><p class="Textbody"><span class="T19">El fenómeno de las redes sociales, blogs, fotoblogs, wikis entre otros, demuestra que la nueva Web la construyen las personas. Este cambio en la web no es casual, la mayor interactividad lograda con técnicas como Ajax o Ria permitió que las personas la utilicen más. Otro aspecto importante, es que la nueva web esta interrelacionada: los servicios de internet se comunican entre sí todo el tiempo. Web 2.0 se caracteriza porque diferentes sitios web se comunican para brindar mayor funcionalidad e integración. De este modo por ejemplo podemos utilizar una cuenta openID</span><span class="FootnoteReference"><span class="T19" /></span><span class="T19"> para realizar un comentario en un post de blogger</span><span class="FootnoteReference"><span class="T19" /></span><span class="T19">. </span></p><p class="Textbody">Una arquitectura de software basada en la comunicación y distribuida como SOA puede ser una herramienta esencial para implementar una web abierta y colaborativa. Una web que busca exponer servicios que se comunican entre sí, brindando funcionalidad distribuida, e desarrollo de una este tipo de arquitectura más fácil de desarrollar con una arquitectura SOA.  </p><p class="Textbody">Lo que esta tesis persigue es analizar si es posible desarrollar una aplicación web 2.0 con arquitectura SOA Open Source, distinguiendo las ventajas y desventajas que nos brinda SOA para este tipo de aplicaciones. Para lograr este objetivo se desarrollará una aplicación web 2.0 con arquitectura SOA.</p><p class="Textbody"> </p><h2 class="Heading2"><a name="Problema" />Problema</h2><p class="P22"> </p><p class="Textbody">¿Es posible desarrollar aplicaciones Web 2.0 con una arquitectura SOA Open Source? ¿Cual son las ventajas y desventajas de la arquitectura SOA para el desarrollo de aplicaciones web 2.0?  </p><p class="P20"> </p><h2 class="Heading2"><a name="Objetivos" />Objetivos</h2><p class="Textbody"> </p><ul style="margin-left:1.25cm;"><li class="P62" style="margin-left:0cm;"><p class="P62" style="margin-left:0.25cm;">Definir si es posible implementar el estilo arquitectónico SOA en aplicaciones web 2.0  </p></li><li class="P62" style="margin-left:0cm;"><p class="P62" style="margin-left:0.25cm;">Analizar como implementar la arquitectura orientada a servicio. </p></li><li class="P63" style="margin-left:0cm;"><p class="P63" style="margin-left:0.25cm;"><span class="T6">Identificar las </span><span class="T14">diferentes ventajas y desventajas de desarrollar una aplicación web 2.0 con una arquitectura SOA.</span></p></li></ul><p class="Textbody"> </p><ul style="margin-left:1.25cm;"><li class="P64" style="margin-left:0cm;"><p class="P64" style="margin-left:0.25cm;">Definir una arquitectura SOA para desarrollar una aplicación Web 2.0 con tecnologías Open Sources. </p></li><li class="P64" style="margin-left:0cm;"><p class="P64" style="margin-left:0.25cm;">Identificar los diferentes frameworks Java que se pueden utilizar para este fin, y definir cual es el más conveniente.  </p></li><li class="P64" style="margin-left:0cm;"><p class="P64" style="margin-left:0.25cm;">Implementar una arquitectura SOA con el framework seleccionado. </p></li><li class="P64" style="margin-left:0cm;"><p class="P64" style="margin-left:0.25cm;">Analizar ventajas y desventajas que nos brinda la utilización SOA en el desarrollo de una web 2.0. </p></li></ul><p class="Textbody"> </p><h2 class="P51"><a name="Justificaci_C3_B3n_y_Relevancia" />Justificación y Relevancia </h2><p class="Textbody"> </p><p class="Textbody">Esta tesis se desarrolla sobre la tecnología Java ya que es la que actualmente cuenta con la mayor cantidad de Frameworks de desarrollo SOA, cuenta con herramientas Open Source de gran calidad, y diferentes proveedores, lo cual hace más enriquecedor su análisis. </p><p class="Textbody">Existen múltiples Frameworks SOA de diferentes proveedores, pero no hay una clara visión, de la utilidad de implementar SOA para aplicaciones Web 2.0. Esta tesis comprobará si es posible implementar una aplicación web 2.0 con SOA Open Source y marcará las ventajas de desarrollar con SOA.  </p><p class="Textbody">La tesis a desarrollar será un claro estudio para que el arquitecto de una aplicación Web 2.0 pueda adoptar el estilo arquitectónico SOA conociendo de antemano sus posibilidades, beneficios y precauciones.  </p><p class="Textbody"> </p><h2 class="Heading2"><a name="Factibilidad_del_estudio" />Factibilidad del estudio</h2><p class="Textbody"> </p><p class="Textbody">El software de desarrollo que se utilizará no necesita grandes requerimientos para ser ejecutado sobre una PC. El mayor desafío se presentará cuando se necesite obtener datos sobre  performance, dado que resulta muy difícil probar el comportamiento de la aplicación ante un acceso a grandes volúmenes de datos por parte de muchos usuarios en forma concurrente.   </p><p class="Textbody"><span class="T45">Factibilidad Económica</span><span class="T12">:</span><span class="T50"> </span><span class="T17">El costo del estudio es relativamente bajo dado que el software que se utilizará para esta investigación  es de distribución gratuita, la adquisición de los mismos puede realizarse a través de Internet. Se trabajará solo con frameworks de distribución gratuita y open sources.</span></p><p class="Textbody"><span class="T45">Factibilidad Operativa</span><span class="T12">:</span><span class="T50"> </span><span class="T17">operativamente el desarrollo del proyecto es factible dado que la información sobre el tema es accesible a través de libros e Internet y los frameworks con los que se trabajara son de distribución libre lo que conlleva a su fácil adquisición y la documentación de los mismos.</span><span class="T18"> Como se señalo anteriormente el mayor desafío se presentará cuando sea necesario recopilar datos sobre  performance, es muy difícil simular escenarios con muchos usuarios trabajando de forma concurrente. </span></p><p class="Textbody"> </p><h2 class="P51"><a name="Marco_Te_C3_B3rico" />Marco Teóric<span class="T56">o</span></h2><p class="Textbody"> </p><p class="Textbody">En la Facultad nos enseñan que para comprender una realidad compleja se debe dividirla y de esta manera analizar cada componente y comprenderlo para luego analizar la totalidad de la realidad. Utilizaremos este método para definir la Arquitectura Orientada a Servicios. Primero analicemos el término servicio. </p><p class="Textbody">Servicio tradicionalmente se ha utilizado para describir una función de negocio autocontenida, con una interfaz bien definida y estable, que recibe requerimientos de sus clientes. El servicio no depende del contexto de sus clientes y puede ser consumido por varios sistemas sin ser modificado. Los servicios son instalados (o desplegados) una única vez, esto lo diferencia de los componentes que deben ser incluidos dentro del contexto de cada aplicación que requiera de su uso y permanecen disponibles, sin consumir recursos hasta que son invocados. </p><p class="Textbody">Propiedades de un servicio: </p><ul style="margin-left:2.5cm;"><li class="P65" style="margin-left:0cm;"><p class="P65" style="margin-left:0.25cm;">Interfaz bien definida. </p></li><li class="P65" style="margin-left:0cm;"><p class="P65" style="margin-left:0.25cm;">Autocontenido. </p></li><li class="P65" style="margin-left:0cm;"><p class="P65" style="margin-left:0.25cm;">No depende del contexto de sus clientes. </p></li><li class="P65" style="margin-left:0cm;"><p class="P65" style="margin-left:0.25cm;">No requiere ser desplegado con cada cliente. </p></li></ul><p class="Textbody"> </p><p class="Textbody"><span class="T15">Luego de definir servicio especificaremos arquitectura. Una definición reconocida es la de Clements: “La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones”.</span><span class="FootnoteSymbol"><span class="T15" /></span><span class="T15"> </span></p><p class="Textbody">Una vez aclarada la definición de servicio y arquitectura, podemos avanzar sobre la de SOA. Se podría definir como un estilo arquitectónico que propone modelar la empresa como una colección de servicios expuestos en la red. Nos propone ver a la empresa no como sistemas aislados sino como un todo.  </p><p class="Textbody"><span class="T15">La principal utilidad de los servicios web es que promueven la interoperabilidad entre diferentes plataformas, sistemas y lenguajes. Con servicios web, por ejemplo, sería posible integrar una aplicación Windows desarrollada con Microsoft .NET con una aplicación desarrollada en J2EE</span><span class="FootnoteSymbol"><span class="T15" /></span><span class="T15"> desplegada en un servidor de aplicaciones bajo un sistema Linux. </span></p><p class="Textbody">Alrededor de los Web services, que dominan el campo de un estilo SOA más amplio que podría incluir otras opciones, se han generado las controversias que usualmente acompañan a toda idea exitosa. Al principio hasta resultaba difícil encontrar una definición aceptable y consensuada que no fuera una fórmula optimista de mercadotecnia. El grupo de tareas de W3C, por ejemplo, demoró un año y medio en ofrecer la primera definición canónica adecuada, que no viene mal reproducir aquí: </p><p class="Textbody"><span class="T15">“Un Web service es un sistema de software diseñado para soportar interacción máquina-a-máquina sobre una red. Posee una interfaz descripta en un formato procesable por máquina (específicamente WSDL</span><span class="T15" /><span class="T15">). Otros sistemas interactúan con el Web service de una manera prescripta por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una serialización en XML en conjunción con otros estándares relacionados a la Web” </span><span class="FootnoteSymbol"><span class="T15" /></span></p><p class="Textbody">Un servicio es una entidad de software que encapsula funcionalidad de negocios y proporciona dicha funcionalidad a otras entidades a través de interfaces públicas bien definidas.  </p><p class="Textbody">Los componentes del estilo (o sea los servicios) están débilmente acoplados. El servicio puede recibir requerimientos de cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin rendir cuentas a quienes lo requieran. Los servicios son las unidades de implementación y diseño.  </p><p class="Textbody">Como todos los otros estilos, las SOA poseen ventajas y desventajas. Como se trata de una tecnología que está en su pico de expansión, sus virtudes y defectos varían con el tiempo.  </p><p class="Textbody"> </p><p class="Textbody"> </p><div class="Textbody"><img width="743" height="400" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr2" /></div><p class="Marginalia"><span class="T26">Un sistema sencillo basado en servicios.</span><span class="T25"> </span><span class="T13">Una aplicación además de implementar sus propios componentes de negocio y datos, también puede reutilizar la funcionalidad de servicios existentes en la red empresarial.</span><span class="FootnoteReference"><span class="T13" /></span></p><p class="Textbody"> </p><p class="Textbody"><span class="T56">SOA no es un concepto concreto para un área de la empresa, sino que dependiendo del punto de vista que se emplea. Ya que un ejecutivo de negocio lo puede ver como un conjunto de servicios de negocio, un arquitecto de software lo verá como un estilo arquitectónico y el desarrollador un conjunto de estándares, herramientas y tecnologías concretas que permiten llevar a cabo sus tareas.</span> Esta tesis se centrará en la visión del desarrollador buscando las mejores herramientas para el desarrollo de Web Services en Java. </p><p class="Textbody">Actualmente en el mercado se encuentran múltiples frameworks para implementar el modelo SOA, algunos basados en el modelo empresarial de Java y otros no. Además hay que analizar la madurez de la solución y la aceptación que tiene en los programadores.  </p><p class="P21"> </p><h2 class="Heading2"><a name="Hip_C3_B3tesis" />Hipótesis</h2><p class="P25"> </p><p class="Textbody">Es posible implementar una aplicación Web 2.0 con una arquitectura SOA Open Source. </p><p class="P26" /><p class="Textbody"> </p><p class="Textbody">Las variables se pueden englobar en tres: </p><ol style="margin-left:1.75cm;list-style-type:decimal; "><li class="P66" style="margin-left:0cm;"><p class="P66" style="margin-left:0.25cm;">El costo. </p></li><li class="P66" style="margin-left:0cm;"><p class="P66" style="margin-left:0.25cm;">La performance. </p></li><li class="P66" style="margin-left:0cm;"><p class="P66" style="margin-left:0.25cm;">La flexibilidad. </p></li></ol><p class="Textbody">En la variable costo vamos a tener: el tiempo de desarrollo, el costo de capacitación y el costo de hardware que conlleva la utilización de estas tecnologías. </p><p class="Textbody">En la variable de performance tenemos: tiempo de respuesta a una petición, utilización de recursos. </p><p class="Textbody">La flexibilidad engloba la capacidad de adquirir  nuevos servicios en el tiempo, la adaptación de la aplicación a los cambios de entorno y la problemática que conlleva el cambio.</p><p class="Textbody"> </p><h2 class="P52"><a name="Temas_comprendidos_en_el_proyecto" />Temas comprendidos en el proyecto</h2><p class="Textbody"> </p><ul style="margin-left:1.75cm;"><li class="P67" style="margin-left:0cm;"><p class="P67" style="margin-left:0.25cm;">Conceptos fundamentales sobre el estilo arquitectónico SOA. </p></li><li class="P67" style="margin-left:0cm;"><p class="P67" style="margin-left:0.25cm;">Implementación del modelo SOA Open Source. </p></li><li class="P67" style="margin-left:0cm;"><p class="P67" style="margin-left:0.25cm;">Presentar una conclusión que ayude al lector del proyecto decidir correctamente qué tecnologías le conviene utilizar  </p></li></ul><p class="Textbody"> </p><h2 class="P51"><a name="T_C3_A9cnicas_e_Instrumentos" />Técnicas e Instrumentos</h2><p class="Textbody"> </p><ul style="margin-left:1.25cm;"><li class="P68" style="margin-left:0cm;"><p class="P68" style="margin-left:0cm;">Recolección de información tanto de Internet como de libros. </p></li><li class="P68" style="margin-left:0cm;"><p class="P68" style="margin-left:0cm;">Sondeo de propuestas para solucionar la problemática de la implementación por medio de recreación de ejemplos; testeando no solo la performance, sino la complejidad de diseño, la flexibilidad y eficacia de los mismos según el caso de estudio. </p></li><li class="P68" style="margin-left:0cm;"><p class="P68" style="margin-left:0cm;">Comparar las dimensiones de las variables descriptas a través de un análisis de cada uno de los <span class="T56">software</span> seleccionado en el estudio.</p><p class="P68" style="margin-left:0cm;"> </p></li></ul><p class="P6"> </p><p class="P15"> </p><h1 class="P50"><a name="Introducci_C3_B3n" />Introducción </h1><p class="Standard"> </p><p class="Textbody">A manera de introducción se <span class="T56">mencionará</span> como se va a desarrollar la tesis. Este trabajo se dividirá en dos partes, para mayor compresión. En la primera parte se <span class="T23">definirá</span> conceptos fundamentales del mundo SOA, para luego poder introducirnos en el estudio de un caso práctico con el cual explicaremos <span class="T56">porque</span> es bueno desarrollar aplicaciones Web 2.0 con SOA y herramientas Open Sources.  </p><p class="Textbody">La teoría tiene como objetivo ubicar al lector en el universo SOA dándole un visión general de los productos y cuando es necesario utilizarlos para poder discernir cuales de estos serán correctos utilizar en el desarrollo web 2.0 </p><p class="Textbody">En la segunda parte se <span class="T56">analizará</span> cuales son las ventajas y desventajas de utilizar SOA en el desarrollo web con herramientas open source a través de un ejemplo práctico. Al finalizar esta sección se deberá tener los elementos necesarios para poder concluir si es beneficioso o no el uso de SOA en el mundo web 2.0.</p><p class="Textbody">La conclusión <span class="T56">señalará</span> si es posible utilizar SOA Open Source en desarrollos Web 2.0 y <span class="T56">además se remarcarán los beneficios </span>y desventajas del uso de la arquitectura SOA en dicho<span class="T56"> desarrollo. Buscando </span>contrastar las virtudes de SOA con los requerimientos no funcionales de una Web 2.0. </p><p class="Textbody">Dicha conclusión será consolidada con el desarrollo de un ejemplo que nos permitirá tomar datos reales de un desarrollo y verificando prácticamente la conclusión.  </p><p class="Textbody">Luego de analizar los temas comprendidos en esta tesis, comenzaremos analizando de forma teórica , que es SOA y sus cuáles son sus beneficios.  </p><p class="Textbody"> </p><h1 class="P50"><a name="Desarrollo_Te_C3_B3rico" />Desarrollo Teórico</h1><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFQue_es_SOA_3F" />¿Que es SOA?</h2><p class="Textbody"> </p><p class="Textbody">Un sistema debe comunicarse con el mundo exterior para ser útil; normalmente el sistema se comunica con diferentes usuarios pero es muy común que deba comunicarse con otro sistema de la empresa.  </p><p class="Textbody"><span class="T51">Cada compañía usa un impresionante número de sistemas y a la vez deben mantener interfaces de comunicación entre los mismos. Las empresas tienen sistemas viejos, sistemas ERP que por una cuestión de licencia, costo o tecnología es imposible agregar funcionalidad lo que conlleva a desarrollar un nuevo sistema que provea la funcionalidad faltante en el primero. A pesar de que estos sistemas tienen muy poco en común, resultaba muy difícil justificar su abandono. Al estar tan estrechamente ligados a las operaciones cotidianas del negocio, la sustitución o renovación de estos sistemas resultaba demasiado costosa. Ante esta situación, las compañías encontraron formas distintas de integrar más estrechamente los sistemas, y de facilitar la comunicación entre ellos. Finalmente, todo esto ha llevado a SOA y a la </span><span class="T52">era de la composición</span><span class="T51">.</span></p><p class="Textbody">Normalmente una empresa tiene varios sistemas, los cuales se comunican por medio de interfaces que son difíciles de mantener. Pensar en los web services como una solución para la interoperabilidad entre sistemas, es una solución. Pero podríamos dar un siguiente paso, tomar estos web services, identificarlos según su funcionalidad, organizarlos y coordinarlos para que puedan solucionar requerimientos. Al tener web services orquestados por la arquitectura, la reutilización es óptima y la escalabilidad es inmensa, ya que trabajamos sobre una arquitectura distribuida.  </p><p class="Textbody">“La <span class="T10">Arquitectura Orientada a Servicios</span> (en inglés <span class="T10">S</span>ervice <span class="T10">O</span>riented <span class="T10">A</span>rchitecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.</p><p class="Textbody">Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios, lo cual facilita la interacción entre diferentes sistemas propios o de terceros.”<span class="Refdenotaalpie" /></p><p class="Textbody">SOA es una forma de ver los sistemas, normalmente un sistema se ve como un conjunto de funcionalidades las cuales se encuentran bajo una interfaz y además agrupadas en un sistema, acopladas al mismo. Con SOA los sistemas son conjuntos de funcionalidades las cuales tienen una definición y están publicadas para ser accedidas, el conjunto de funcionalidad son orquestadas por un software que permite decidir el flujo de ejecución.</p><p class="Textbody"><span class="T56">“</span>SOA define las siguientes capas de software:</p><ul style="margin-left:1.25cm;"><li class="P69" style="margin-left:0cm;"><p class="P69" style="margin-left:0cm;"><span class="T10">Aplicaciones básicas</span> - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; </p></li><li class="P69" style="margin-left:0cm;"><p class="P69" style="margin-left:0cm;"><span class="T10">De exposición de funcionalidades</span> - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (servicios web); </p></li><li class="P69" style="margin-left:0cm;"><p class="P69" style="margin-left:0cm;"><span class="T10">De integración de servicios</span> - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración; </p></li><li class="P69" style="margin-left:0cm;"><p class="P69" style="margin-left:0cm;"><span class="T10">De composición de procesos</span> - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio; </p></li><li class="P69" style="margin-left:0cm;"><p class="P69" style="margin-left:0cm;"><span class="T10">De entrega</span> - donde los servicios son desplegados a los usuarios finales. </p></li></ul><p class="Textbody">SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.”<span class="Refdenotaalpie" /></p><h2 class="Heading2"><a name="_C2_BFCu_C3_A1ndo_implementar_SOA_3F" />¿Cuándo implementar SOA?</h2><p class="Textbody"> </p><p class="Textbody">SOA es una arquitectura que cambia totalmente el departamento de IT y también la empresa, migrar a una arquitectura SOA, no es fácil y requiere esfuerzo humano y técnico.  Siempre que se tenga el presupuesto para migrar es bueno hacerlo. Ya que los beneficios de usar una arquitectura SOA, son muchos. </p><p class="Textbody">Para nombrar algunos:  </p><ul style="margin-left:1.25cm;"><li class="P70" style="margin-left:0cm;"><p class="P70" style="margin-left:0.25cm;">No existirán funcionalidades replicada en varios sistemas. </p></li><li class="P70" style="margin-left:0cm;"><p class="P70" style="margin-left:0.25cm;">No existirán funcionalidades o procesos de integración entre sistemas. </p></li><li class="P70" style="margin-left:0cm;"><p class="P70" style="margin-left:0.25cm;">Mayor flexibilidad e integración. </p></li><li class="P70" style="margin-left:0cm;"><p class="P70" style="margin-left:0.25cm;">Bajo acoplamiento.</p></li><li class="P70" style="margin-left:0cm;"><p class="P70" style="margin-left:0.25cm;">Integración basada en estándares. </p></li></ul><h2 class="Heading2"><a name="_C2_BFQue_define_la_Arquitectura_SOA_3F" />¿Que define la Arquitectura SOA?</h2><p class="P36"> </p><p class="P36">La arquitectura SOA define : </p><ul style="margin-left:1.25cm;"><li class="P71" style="margin-left:0cm;"><p class="P71" style="margin-left:0cm;">Los servicios.  </p></li><li class="P71" style="margin-left:0cm;"><p class="P71" style="margin-left:0cm;">Como localizar un servicio. </p></li><li class="P71" style="margin-left:0cm;"><p class="P71" style="margin-left:0cm;">Como conseguir que se comuniquen diferentes servicios. </p></li><li class="P71" style="margin-left:0cm;"><p class="P71" style="margin-left:0cm;">Como encajar diferentes servicios para que funcionen como un sistema. </p></li></ul><p class="Textbody"><span class="T54">En una SOA, los servicios se encuentran documentados en un repositorio denominado </span><span class="T55">registro</span><span class="T54">, se ensamblan mediante las llamadas </span><span class="T55">aplicaciones compuestas</span><span class="T54">, y el plano que le sirve de guía es lo que se conoce como </span><span class="T55">esquema global</span><span class="Refdenotaalpie"><span class="T55" /></span><span class="T55"> de la SOA.</span></p><p class="P36">Para mayor facilidad de los conceptos que conllevan el estilo arquitectónico SOA, vamos a analizar primero los servicios y luego las herramientas que nos permiten administrarlos. </p><h2 class="Heading2"><a name="Servicios." />Servicios.</h2><p class="P13"> </p><p class="Textbody">Los servicios son funcionalidad <span class="T56">necesaria</span> para la empresa, es decir son funcionalidad expuesta a otros servicios, sistemas o una interfaz gráfica. Los cuales fueron concebidos para solucionar un requerimiento. Los servicios son los ladrillos de nuestra arquitectura SOA. Ellos pueden contener lógica de negocio, acceso a bases de datos, accesos a otros servicios, etc.    </p><p class="Textbody">Los servicios están <span class="T56">descriptos </span>en una interfaz que indica como utilizarlos. Pero los servicios nunca exponen como funcionan<span class="T56">; son una c</span>aja negra. Lo que permite cambiar un servicio fácilmente por otro, favoreciendo la mantenibilidad y agilidad de desarrollo. Los servicios exponen como se utilizan pero no exponen como funcionan. </p><p class="Textbody">Los servicios pueden acoplarse para formar nuevos servicios, que solucionan nuevos requerimientos, esto ayuda a que no se duplique el código. Los servicios son atómicos y sin estado lo que permite distribuirlos en diferentes maquinas favoreciendo la escalabilidad de los sistemas.  </p><h2 class="Heading2"><a name="Gobierno_SOA" />Gobierno SOA</h2><p class="Standard"> </p><p class="Textbody">Los servicios por si solos son incompletos, necesitan una arquitectura que los mantenga y soporte sus ventajas. Por ejemplo a la hora de desarrollar un nuevo servicio ¿cómo se si no existe ya? O ¿existen servicios que pueden ayudar al nuevo servicio? Por lo tanto debo tener un registro donde registrar mis servicios, en el cual puedo buscar los servicios ya existentes.  </p><p class="Textbody">El gobierno SOA es el conjunto de roles, políticas y procedimientos que sirven de guía para la adopción de la SOA. Al implementar los componentes tecnológicos de gobierno, está creando la infraestructura para soportar y aplicar estos roles, políticas y procedimientos en toda su SOA. </p><p class="Textbody">Luego de desarrollar los servicios hay que gestionarlos, la gestión de los servicios se le llama gobierno SOA.  </p><p class="Textbody">“Gobierno de SOA es una ampliación del gobierno de IT centrada en el ciclo de vida<span class="Refdenotaalpie" /> de los servicios y en las aplicaciones compuestas en una arquitectura orientada a servicios (SOA) de una organización. La función del gobierno de SOA es definir:</p><ul style="margin-left:1.25cm;"><li class="P73" style="margin-left:0cm;"><p class="P73" style="margin-left:0.25cm;">Derechos para tomar decisiones para el desarrollo, el despliegue y la gestión de nuevos servicios.  </p></li><li class="P73" style="margin-left:0cm;"><p class="P73" style="margin-left:0.25cm;">La supervisión y notificación de procesos para capturar y comunicar los resultados del gobierno. Debido a que las aplicaciones SOA están intrínsecamente fragmentadas, introducen nuevos retos de gobierno. No obstante, con políticas, principios, estándares y procedimientos adecuados, los empresarios pueden darse cuenta de todas las ventajas que ofrece la arquitectura orientada a servicios. Una plataforma de gobierno de SOA eficaz no sólo ayuda a los equipos de IT y negocio a identificar mejor qué proyectos contribuyen más a los objetivos empresariales, sino que también dotan de más facilidades a los empleados para trabajar y colaborar de forma más eficaz definiendo claramente sus roles y sus responsabilidades.”<span class="Refdenotaalpie" /></p></li></ul><p class="Textbody">El Gobierno SOA pretende dotar de los mecanismos de control, procesos, procedimientos y métodos probados en la práctica para garantizar el orden en las decisiones que se tomen en una iniciativa SOA, evitando el caos en cualquier proyecto SOA que se plantee, logrando la efectividad y agilidad esperada en la transición hacia SOA. </p><p class="Textbody">El Gobierno se refiere a los procesos que una empresa establece para garantizar que las acciones realizadas se adhieren a las mejores prácticas, normativas, estándares y principios de arquitectura, con objeto de gobernar la adopción e implementación de SOA.  </p><p class="Textbody">La ausencia del Gobierno SOA puede desembocar en los siguientes problemas:  </p><ul style="margin-left:1.25cm;"><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;"> El Programa SOA entrega resultados inconsistentes.</p></li><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;"> Crecimiento caótico a nivel de infraestructura y servicios.</p></li><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;"> Servicios con funcionalidad redundante. </p></li><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;"> Disponer de servicios que no se pueden reutilizar en la organización. </p></li><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;"> Inconsistencia en la identificación, diseño y uso de los servicios. </p></li><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;"> No se definen métricas para cuantificar el éxito. </p></li><li class="P74" style="margin-left:0cm;"><p class="P74" style="margin-left:0cm;">Ausencia de coordinación entre proyectos.  </p></li></ul><p class="Textbody">La definición de una Estrategia de Gobierno SOA proporciona la coherencia necesaria para todas las acciones que se lleven a cabo en un Plan de Adopción SOA, siguiendo un enfoque incremental de adopción en distintas fases para reducir riesgos, y proporcionando un modelo de gobierno que constituya un marco de referencia para las decisiones que se tomen.  </p><p class="Textbody">Por lo tanto podríamos definir a SOA como la suma de servicios y gobierno SOA.  </p><p class="Textbody">El Gobierno SOA comprende varias herramientas que permiten gobernar los servicios: </p><ul style="margin-left:1.75cm;"><li class="P75" style="margin-left:0cm;"><p class="P75" style="margin-left:0.25cm;">Registro de servicios, permite registrar nuestros servicios y consultar servicios existentes. </p></li><li class="P75" style="margin-left:0cm;"><p class="P75" style="margin-left:0.25cm;">Bus de servicios o ESB (Enterprise Service Bus) facilita la comunicación entre diferentes servicios. </p></li><li class="P75" style="margin-left:0cm;"><p class="P75" style="margin-left:0.25cm;">Orquestación y coreografía, herramienta que permite definir la interoperabilidad de los servicios. </p></li><li class="P75" style="margin-left:0cm;"><p class="P75" style="margin-left:0.25cm;">CEP (Complex Event Processing) y<span class="T11"> </span>Procesador de flujos de eventos o ESP(Event Stream Processing) son herramientas para diseñar, gestionar y monitorizar los eventos que fluyen a través de un entorno orientado a EDA<span class="Refdenotaalpie" /> dado.</p></li><li class="P75" style="margin-left:0cm;"><p class="P75" style="margin-left:0.25cm;">Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) facilita la integración con aplicaciones o bases de datos de una empresa. </p></li></ul><p class="Textbody">A la vez existen muchos frameworks que nos permiten desarrollar servicios SOA, con mayor flexibilidad y rapidez. Permitiendo obtener más fácilmente los beneficios del uso SOA y a la vez preparados para ser Gobernados por el gobierno SOA. En la tesis nos centraremos en el estándar de OASIS<span class="Refdenotaalpie" />,  SCA (Service Component Architecture). SCA es un estándar que simplifica el desarrollo SOA basándose en el concepto de componentes. Nos centraremos en esta especificación dado que brinda gran facilidad en el desarrollo, además promueve el uso de las mejores prácticas. </p><p class="Textbody">No necesariamente se deben tener todas las herramientas descriptas para conformar el gobierno SOA. Se deben adoptar las herramientas que satisfagan las necesidades propias de la empresa que adopta SOA. A continuación se describirá las herramientas SOA.  </p><h2 class="P53"><a name="Registro_o_repositorio" />Registro o repositorio</h2><p class="Standard"> </p><p class="Textbody">Sólo se puede gobernar lo que se ve, por lo tanto, el primer paso es crear un único catálogo maestro en el que estén visibles, para todas las partes interesadas, los elementos más importantes de su SOA. El registro/repositorio se ha erigido en el estándar para la creación de este tipo de sistema de registros. </p><p class="Textbody">El registro es donde se publican los servicios y es donde se debe consultar los servicios existentes para poder consumirlos. </p><p class="Textbody">El registro puede ser desde una base de datos LDAP<span class="Refdenotaalpie" /> a una entrada en wiki de la empresa, dependiendo de los requerimientos de la empresa. Pero siempre debe tener al menos esta información:</p><ul style="margin-left:1.25cm;"><li class="P76" style="margin-left:0cm;"><p class="P76" style="margin-left:0.25cm;">Punto final del servicio (donde esta publicado). </p></li><li class="P76" style="margin-left:0cm;"><p class="P76" style="margin-left:0.25cm;">Descripción del servicio.</p></li><li class="P76" style="margin-left:0cm;"><p class="P76" style="margin-left:0.25cm;">Ubicación WSDL si usamos servicios SOAP o como se utiliza el servicio. </p></li><li class="P76" style="margin-left:0cm;"><p class="P76" style="margin-left:0.25cm;">Numero de revisión y versión.  </p></li></ul><p class="Standard"> </p><h2 class="Heading2"><a name="ESB__28Enterprise_Service_Bus_29" />ESB (Enterprise Service Bus)</h2><p class="Standard"> </p><p class="Textbody">Si en nuestra organización los sistemas se comunican entre si por medio de un patrón punto a punto, los canales de comunicación se multiplica<span class="T56">rían y a la vez se debería  implementar procesos de traducción protocolos p</span>ara que cada sistema pueda comunicarse en el protocolo que fue concedido, veamos un ejemplo:</p><p class="Textbody" /><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody">Las comunicaciones no están centralizadas lo que trae mayor canal de comunicación y como cada aplicación habla un idioma diferente: REST, SOAP, RMI, etc. las funcionalidades de traducción se duplican.  </p><p class="Textbody">Por lo tanto, si tuviéramos las comunicaciones en un Bus simplificaremos la comunicación y además no se duplicaría el código de traducción ya que se encuentra centralizado </p><p class="Textbody" /><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody" /><p class="Textbody"><span class="T33">“</span>En una arquitectura tan compleja, el ESB representa el elemento de software que media entre las aplicaciones empresariales y permite la comunicación entre ellas. Idealmente el ESB tendría que ser capaz de sustituir todo contacto directo con las aplicaciones en el bus, de modo que toda la comunicación tenga lugar a través del bus. Para lograr este objetivo, el bus debe encapsular la funcionalidad que ofrecen las aplicaciones que lo componen de un modo significativo. Esto sucede normalmente con la implantación de un modelo de mensaje de empresa. El modelo de mensajes define un conjunto de mensajes normalizado que el ESB recibe y transmite. Cuando un ESB recibe un mensaje, lo encamina hacia la aplicación apropiada. A menudo sucede que, como esa aplicación se ha desarrollado sin el mismo modelo de mensajes, el ESB tendrá que transformar el mensaje a un formato de compatibilidad (<span class="T29">legacy format</span>) que la aplicación sea capaz de interpretar. Un "adaptador" de software lleva a cabo la tarea de efectuar estas transformaciones (al igual que lo hace un adaptador físico). No hay acuerdo en si se debe considerar este adaptador como constituyente del ESB o no.</p><p class="Textbody">Los ESB se basan en la conexión precisa de un modelo de mensajes de empresa y la funcionalidad ofrecida por las aplicaciones. Si el modelo de mensajes no encapsula completamente la funcionalidad de las aplicaciones, entonces otras aplicaciones que desean esa funcionalidad pueden tener que rodear el bus e invocar directamente a las aplicaciones no emparejadas. Esto supone violar todos los principios señalados más arriba y desprecia muchas de las ventajas de la utilización de un ESB.<span class="T33">”</span><span class="Refdenotaalpie"><span class="T33" /></span></p><p class="Textbody">Un bus de servicios empresariales o ESB (Enterprise Service Bus) es una buena elección para la capacitación de servicios, si la aplicación que está intentando habilitar proporciona una interfaz para conectarla a otros sistemas. Un buen ESB ofrece todas las herramientas que necesita para crear servicios XML que aprovechen ese API: </p><ul style="margin-left:1.25cm;"><li class="P77" style="margin-left:0cm;"><p class="P77" style="margin-left:0.25cm;">Compatibilidad con varios protocolos: Los ESB implementan un gran abanico de protocolos, especialmente algunos ya pasados de moda como por ejemplo: RPC. Un buen ESB se ocupa de todos los detalles para poder utilizar un protocolo, de forma prácticamente transparente.</p></li><li class="P77" style="margin-left:0cm;"><p class="P77" style="margin-left:0.25cm;">Compatibilidad con diferentes patrones de comunicación: El medio más común que utiliza un ESB para comunicarse con una aplicación es mediante el patrón de petición/respuesta (request/reply). Según este patrón, el ESB envía una consulta a la aplicación correspondiente mediante un protocolo compatible y la aplicación le remite inmediatamente la respuesta. Pero muchos sistemas de misión crítica utilizan patrones de comunicación más sofisticados y orientados a mensajes, como ‘publicación/suscripción’ o ‘envía y olvida’. Un buen ESB consigue que la conexión a un sistema mediante patrones avanzados de comunicación sea un proceso sencillo, al igual que la combinación y compatibilización de patrones según se necesitan.</p></li><li class="P77" style="margin-left:0cm;"><p class="P77" style="margin-left:0.25cm;">Compatibilidad con diferentes formatos de mensajes: Los ESB son también muy buenos en la traducción de mensajes XML a un lenguaje comprensible para sus aplicaciones o viceversa. No importa que se trate de un lenguaje MIME, sólo texto o archivos planos. El ESB ejecuta todas las traducciones y transformaciones necesarias para convertir hacia o desde XML. </p></li><li class="P77" style="margin-left:0cm;"><p class="P77" style="margin-left:0.25cm;">Adaptadores: Los ESB pueden gestionar todos los detalles necesarios para conectar las aplicaciones existentes. Los mejores ESB ocultan la compleja labor de conectar una aplicación tras interfaces comunes y coherentes denominadas adaptadores. Estos reducen enormemente la curva de aprendizaje de los desarrolladores de servicios, que en lugar de ocuparse de las complejas conexiones entre diferentes sistemas, pueden centrarse en exponer las funcionalidades existentes como servicios. </p></li></ul><p class="Textbody">Contar con un ESB en una empresa es muy importante dado que contribuye a la sana convivencia de diferentes aplicaciones que se encuentran implementadas en diferentes plataformas y hablan diferentes idiomas. </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><div class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /><img width="433" height="431" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr3" /></div><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><p class="Textbody"><a href="http://www.espaciosoa.net/2007/09/17/orquestacion-y-coreografia/" /></p><h2 class="P53"><a name="Orquestaci_C3_B3n_y_Coreograf_C3_ADa." />Orquestación y Coreografía.</h2><p class="Textbody"> </p><p class="Textbody">La integración se debe llevar a cabo mediante un mecanismo que permita que los servicios cooperen entre ellos. Para ello comúnmente se utilizan dos términos: La orquestación y la coreografía. Hablamos de orquestación de servicios cuando es controlado por una única unidad, es decir un cliente y un servicio establecen un acuerdo con respecto al transporte de mensajes y al contenido. Un proceso es una coreografía de servicios cuando las colaboraciones son definidas entre cualquier tipo de aplicaciones. </p><p class="Textbody">La coreografía brinda reglas que revelan como múltiples componentes pueden colaborar entre pares, lo que denominamos peer-to-peer, y de que forma o en que secuencia. Esta colaboración se realiza mediante el intercambio de mensajes. Una <span class="Emphasis">coreografía</span> describe la colaboración entre más de un servicio para lograr un objetivo común. Por lo tanto no se centra en un servicio en particular, pero si en un objetivo que tiene que cumplir el flujo de proceso. Para ello, la lógica de control es distribuida sobre los servicios participantes. Para diseñar una coreografía, se debe describir primero las interacciones que los servicios tienen que realizar entre sí para cumplir el objetivo y las relaciones que existen entre estas interacciones. Una <span class="Emphasis">coreografía</span> no describe las acciones que son realizadas internamente por el servicio principal para realizar el flujo de procesos.</p><p class="Textbody">Si usted alguna vez pudo apreciar una presentación de ballet, puede haberse percatado como cada integrante del equipo (servicios) inicia y finaliza un conjunto de movimientos (flujo de proceso), estos movimientos siguen una trilla (interacciones entre los servicios) musical determinada.</p><p class="Textbody">Una <span class="Emphasis">orquestación</span> describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso. Esto quiere decir, que el enfoque se centra sobre un servicio en particular, y la lógica de control es centralizada sobre el servicio principal el cual implementa el comportamiento. Para diseñar una <span class="Emphasis">orquestación</span>, se describe las interacciones que el servicio principal tiene con las otras partes (servicios, adaptadores, interfaces, etc.) y las acciones que el servicio principal realiza internamente para realizar el flujo de proceso. Una <span class="Emphasis">orquestación</span> es ejecutada por una máquina de orquestación. Por lo que es llamado proceso ejecutable.</p><p class="Textbody">Para entender mejor la definición de <span class="Emphasis">orquestación</span>, imagine como un maestro de una orquesta sinfónica dirige y controla a cada uno de los integrantes (servicios) de la orquesta con el fin de poder lograr un objetivo común (un flujo de proceso), que es el de poder establecer una melodía armoniosa basada en un conjunto de especificaciones (objetivo principal y interrelaciones entre servicios) que contienen las notas, que instrumentos deben tocarse, que notas deben tocar cada uno de esos instrumentos y cuando deben iniciar o detener sus melodías. </p><p class="Textbody">Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores). Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio de diversos servicios web. </p><p class="Textbody">La orquestación es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). La Orquestación podría verse como la ejecución de un proceso de negocio definido en BPM o BPEL y que puede ser ejecutado por un motor BPM o BPEL. </p><p class="Textbody">La coreografía se define mediante WS-CDL y la orquestación puede definirse con BPM o BPEL veamos cada uno de estos lenguajes. </p><h3 class="P47"><a name="WS-CDL" />WS-CDL</h3><p class="Textbody">Cuando hablamos de coreografía de Servicios Web se debe mencionar a WS- CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web. Este lenguaje, basado en XML, permite lograr interacción entre servicios Web. Dicha interacción es independiente del lenguaje o de la plataforma utilizada.</p><p class="Textbody">La coreografía es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios procesos particulares (varios flujos de control). WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web.  </p><h3 class="Heading3"><a name="BPM" />BPM</h3><p class="Textbody">BPM (Business Process Management) podría ser definido como un Flujo de trabajo o workflow<span class="Refdenotaalpie" />, es una forma de representar los procesos, los cuales son seguidos por el sistema. Permitiendo en tiempo de ejecución modificar el workflow y que se aplique estos cambios sin volver a compilar ni a bajar o subir la aplicación.</p><p class="Textbody">BPM marca al sistema el orden de ejecución de procesos dando la flexibilidad para poder modificar este orden cuando se lo desee. Esto permite centrarse en la lógica de negocio dando el poder de decisión al usuario final el cual por medio de un editor puede modificar el workflow como crea más conveniente. Se centra en el negocio.  </p><p class="Textbody">BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno. </p><p class="Textbody">El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos. </p><p class="Textbody">La tecnología BPM incluye lo necesario para diseñar, representar, analizar y controlar los procesos de negocio operacionales: </p><ul style="margin-left:1.25cm;"><li class="P78" style="margin-left:0cm;"><p class="P78" style="margin-left:0.25cm;">El diseño y modelado de procesos posibilitan que, de forma fácil y rigurosa, pueda definir procesos que abarcan cadenas de valor y coordinar los roles y comportamientos de todas las personas, sistemas y otros recursos necesarios. </p></li><li class="P78" style="margin-left:0cm;"><p class="P78" style="margin-left:0.25cm;">La integración le permite incluir en los procesos de negocio cualquier sistema de información, sistema de control, fuente de datos o cualquier otra tecnología. La arquitectura orientada a servicios (SOA) lo hace más rápido y fácil. </p></li><li class="P78" style="margin-left:0cm;"><p class="P78" style="margin-left:0.25cm;">La ejecución convierte de forma directa los modelos en acción del mundo real, coordinando los procesos en tiempo real. </p></li><li class="P78" style="margin-left:0cm;"><p class="P78" style="margin-left:0.25cm;">La supervisión de la actividad de negocio (BAM) realiza el seguimiento del rendimiento de los procesos mientras suceden, controlando muchos indicadores, mostrando las métricas de los procesos y tendencias clave y prediciendo futuros comportamientos. </p></li><li class="P78" style="margin-left:0cm;"><p class="P78" style="margin-left:0.25cm;">El control le permite responder a eventos en los procesos de acuerdo a las circunstancias, como cambio en las reglas, notificaciones, excepciones y transferencia de incidentes a un nivel superior. </p></li></ul><p class="Textbody">Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de <span class="T29">BPM</span>. Este conjunto de herramientas son llamadas Business Process Management System y con ellas se construyen aplicaciones <span class="T29">BPM</span>.</p><p class="Textbody">BPM no esta acoplado al mundo SOA, se puede controlar procesos de una aplicación usando BPM sin tener servicios web. Pero BPM se puede utilizar para modelar flujo de trabajo llamando servicios web. Permitiendo una gran flexibilidad el flujo de trabajo no depende de una aplicación sino que esta constituido por servicios referenciados por una URI. El motor BPM no esta acoplado a implementaciones sino que conoce solo interfaces dadas por WSDLs o otros descriptores desacoplando el motor BPM de los servicios. Además se puede extender el motor BPM para que ofrezca información del workflow por servicios web. Proporcionando funcionalidades completas por servicios web.  </p><h3 class="Heading3"><a name="BPEL" />BPEL</h3><p class="Textbody">Business Process Execution Language (lenguaje de ejecución de procesos de negocio), se trata de un lenguaje XML para la especificación de procesos de negocio ejecutables, aplicado principalmente a la orquestación de los servicios web. BPEL es un subconjunto de BPM. Definido para representar workflows de servicios web.  </p><p class="Textbody">La interacción entre servicios web puede ser descripta de dos formas: procesos de negocio ejecutable y procesos de negocio abstracto.  </p><ul style="margin-left:1.25cm;"><li class="P79" style="margin-left:0cm;"><p class="P79" style="margin-left:0.25cm;">Proceso de negocio ejecutable: es el comportamiento real de un participante de una interacción.  </p></li><li class="P79" style="margin-left:0cm;"><p class="P79" style="margin-left:0.25cm;">Proceso de negocio abstracto: es el proceso que no está destinados a ser ejecutados, puede ocultar algunos de los detalles necesarios de las operaciones concretas. Los Procesos abstractos desempeñan una función descriptiva, con más de un caso de uso posible, incluyendo el comportamiento observable y plantilla de proceso. Un proceso abstracto que incluye información como cuándo es mejor esperar para mensajes, cuándo enviar mensajes, cuándo compensar las transacciones fallidas, etc.</p></li></ul><p class="Textbody">BPEL provee un lenguaje para la especificación de Procesos de negocios Ejecutables y Abstractos. De este modo, se extiende el modelo de servicios Web y la posibilidad de interacción para apoyar las transacciones comerciales. WS-BPEL define un modelo de integración interoperable que debería facilitar la expansión de la integración de procesos automatizados, tanto dentro como entre las empresas.</p><p class="Textbody">Bpel fue diseñado con los siguientes objetivos: </p><ol style="margin-left:1.25cm;list-style-type:decimal; "><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Definir procesos de negocio que interactúan con entidades externas a través de operaciones de Web services definidas en archivos WSDL, y que se manifiestan en los servicios Web definen utilizando WSDL. </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Esta basado en xml. No define una representación gráfica de procesos, ni provee algún particular metodología de diseño. </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio. </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Proveer sistemas de control jerárquicos y de estilo grafo, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos.  </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.  </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar.  </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida.  </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo. </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Usar servicios Web como modelo para la descomposición y ensamblaje de procesos.  </p></li><li class="P80" style="margin-left:0cm;"><p class="P80" style="margin-left:0.25cm;">Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible. </p></li></ol><p class="Textbody">BPEL es una herramienta concebida para diseñar workflows basados en web services, esto lo hace una herramienta más apta que BPM para la orquestación de servicios SOA. BPM es más amplio y menos específico para SOA por estas razones nace BPEL. Un lenguaje más específico que suple las deficiencias que tiene BPM. </p><p class="Standard"> </p><h2 class="P51"><a name="CEP__28Complex_Event_Processing_29_y_ESP__28Event_Stream_Processing_29" />CEP (Complex Event Processing) y ESP (Event Stream Processing)</h2><p class="Textbody"> </p><p class="Textbody">Las tecnologías emergentes como el Procesamiento de Eventos Complejos (Complex Event Processing o CEP) y el Procesamiento de Flujos de Eventos (Event Stream Processing o ESP) han comenzado a ocuparse de problemas de mayor complejidad que no podían resolverse con el procesamiento de eventos tradicional. Por ejemplo, con CEP se puede “analizar, correlacionar y resumir eventos de bajo nivel en eventos de más alto nivel adecuados para informar a las personas en términos humanos o para desencadenar procesos automáticos.”<span class="Refdenotaalpie" /> CEP y ESP emplean técnicas como la detección de patrones complejos en numerosos eventos, utilizando algoritmos de procesamiento de reglas para la correlación y abstracción de eventos, empleando jerarquías de eventos y relaciones entre los eventos. Los análisis de causalidad, membrecía, oportunidad y procesos impulsados por eventos son capacidades centrales de estas tecnologías.</p><p class="Textbody">ESP y CEP se consideran parte de una tendencia más extensa llamada EDA (event-Driven Architecture) EDA es un estilo arquitectónico, que esta centrado en comunicaciones asíncronas basadas en eventos. Es totalmente complementario a SOA y utiliza mensajes asíncronos en lugar de llamadas a funciones al estilo RPC, para realizar computación distribuida. Un evento es simplemente la acción de algo que está ocurriendo, bien sea un pedido, un aviso de entrega o la finalización del trabajo de un empleado. El sistema que registra el evento (también llamado sensor) genera un objeto de eventos que se envía mediante una notificación. El consumidor de la notificación o receptor puede ser otro sistema que por su parte, utilice el evento para iniciar alguna acción como respuesta. Aquí es donde el concepto de ESP entra en juego.   </p><p class="Textbody">ESP permite analizar los procesos e identificar eventos inusuales, lo que permite a raíz de estos eventos informarlos o ejecutar algún proceso. Por ejemplo una persona que saca del cajero un monto inusual de dinero el sistema podría enviar un e-mail al cliente notificando la extracción. Otro ejemplo podría ser: un servicio demora más de lo normal esto puede generar un evento el cual sea notificado a un servicio que informe al administrador.  </p><p class="Textbody">Implementar ESP en una arquitectura SOA nos facilita su mantenimiento y permite manejar eventos complejos de una forma fácil. </p><h2 class="P51"><a name="EAI__28Enterprise_Application_Integration_29" />EAI (Enterprise Application Integration)</h2><p class="Textbody"> </p><p class="Textbody">EAI (<span class="T29">Enterprise Application Integration</span>, traducido al español como <span class="T29">integración de aplicaciones empresariales</span>) es definido como el uso de software y sistemas de computadora para integrar un conjunto de aplicaciones.</p><p class="Textbody">El propósito de la <span class="T10">EAI</span> es lograr la interoperabilidad y organización del flujo de información entre aplicaciones heterogéneas, es decir, asegurar la comunicación entre las distintas aplicaciones y formar el sistema de información de la empresa, incluso de los clientes, socios o proveedores. </p><p class="Textbody">Por lo tanto, y en primer lugar, un proyecto de EAI implica implementar una arquitectura bajo la cual las distintas aplicaciones se comuniquen entre sí. En consecuencia, esto conlleva el desarrollo de <span class="T10">conectores</span> (<span class="T29">middleware</span>) que posibilitan la interfaz de aplicaciones mediante el uso de distintos protocolos de comunicación (por lo general exclusivos). </p><p class="Textbody">Sin embargo, el proyecto de <span class="T29">EAI</span> va más allá de la interoperabilidad de las aplicaciones: ofrece la posibilidad de definir un workflow entre las aplicaciones; así, representa una alternativa a la ERP<span class="Refdenotaalpie" /> con un enfoque más modular. </p><p class="Textbody">No obstante, la EAI todavía presenta limitaciones relacionadas con la rigidez de los sistemas heredados (en inglés <span class="T29">legacy</span>), porque se debe modificar el middleware cuando hay cambios importantes en las aplicaciones.</p><p class="Textbody">Cuando los sistemas no pueden compartir su información efectivamente se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor en lugar de enfocarse en la coordinación de labores operativas. </p><p class="Textbody">Durante varias generaciones, los sistemas de las empresas han servido para un propósito especifico a un único usuario o grupo de usuarios, los cuales actúan como la interfaz de dicho sistema con el resto de la organización, con lo cual se ha limitado su conexión con otros sistemas modernos o más amplios en la empresa, más aún por la creciente demanda de las empresas por compartir datos y usarlos en sus procesos sin tener que realizar cambios en sus aplicaciones o en sus estructuras de datos.</p><p class="Textbody">Uno de los retos que encaran las organizaciones modernas es darles a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones. </p><p class="Textbody">EAI, como una disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para ciertamente mejorar las organizaciones, tratando de trascender el objetivo de conectar las aplicaciones individuales para buscar ser un mecanismo de incrementar el conocimiento de la organización y crear ventajas competitivas futuras a la empresa. </p><p class="Textbody">La integración de aplicaciones de empresa ha incrementado su importancia porque la computación en las empresas frecuentemente toma la forma de islas de información. Esto ocasiona que el valor de los sistemas individuales no sea aprovechado al máximo debido a su mismo aislamiento. </p><p class="Textbody">Si la integración se aplica sin seguir un enfoque estructurado de EAI, las conexiones punto a punto crecen al interior de la organización resultando en una masa imberbe que es difícil de mantener. Esto se denota normalmente como el espagueti, en alusión al equivalente en programación: el código espagueti. </p><p class="Textbody">EAI puede ser usado con diferentes fines: </p><ul style="margin-left:1.25cm;"><li class="P81" style="margin-left:0cm;"><p class="P81" style="margin-left:0cm;">Integración de datos (información): asegurando que la información en varios sistemas es consistente. Esto también se conoce como EII (Enterprise Information Integration).  </p></li><li class="P81" style="margin-left:0cm;"><p class="P81" style="margin-left:0cm;">Integración de procesos: enlace de los procesos de negocios entre diferentes aplicaciones.  </p></li><li class="P81" style="margin-left:0cm;"><p class="P81" style="margin-left:0cm;">Independencia de proveedor: extrayendo las políticas o reglas del negocio de las aplicaciones e implementándolas en un sistema EAI, de forma que cualquiera de las aplicaciones usadas pueda ser cambiada sin que dichas reglas de negocio deban ser reimplementadas.  </p></li><li class="P81" style="margin-left:0cm;"><p class="P81" style="margin-left:0cm;">Facade común: Un sistema EAI puede actuar como el front-end de un cúmulo de aplicaciones, proporcionando una interfaz de acceso única y consistente a esas aplicaciones y aislando a los usuarios sobre la interacción con distintas aplicaciones. </p></li></ul><p class="Textbody">Luego de definir las principales herramientas SOA, vamos a analizar como desarrollar en sobre una arquitectura SOA y como nuestro desarrollo puede ayudar a la integración de las herramientas de Gobierno SOA.  </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFC_C3_B3mo_se_desarrolla_sobre_una_arquitectura_SOA_3F" />¿Cómo se desarrolla sobre una arquitectura SOA?</h2><p class="Textbody"> </p><p class="Textbody">El desarrollo sobre una arquitectura SOA debe siempre tener en cuenta las funcionalidades desarrolladas y debe consumir estos servicios y exponer las nuevas funcionalidades. Por lo tanto es importante tener un registro actualizado donde se registran los servicios desarrollados y si la empresa cuenta con sistemas heredados con servicios expuestos se debe realizar un relevamiento de los servicios desarrollados y reflejarlos en el registro. Que el registro esté actualizado y sea visual para todos los desarrolladores<span class="T56"> es vital para que</span> no exista comportamiento replicado. </p><p class="P27">El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad. </p><p class="Textbody">El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO<span class="Refdenotaalpie" />  y publicar la funcionalidad por medio de servicios o utilizar el patrón facade<span class="Refdenotaalpie" />. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas<span class="Refdenotaalpie" /> sumado a la arquitectura SOA.</p><p class="Textbody">Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás. </p><p class="Textbody">Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.  </p><p class="Textbody"> </p><p class="Textbody" /><p class="Textbody">En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.  </p><p class="Textbody">Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos. </p><p class="Textbody">También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección. Veamos en mayor detalle SCA para poder discutir qué tecnologías es mejor elegir.  </p><p class="Textbody"> </p><h2 class="P51"><a name="SCA" />SCA</h2><p class="Textbody"> </p><p class="Textbody">Podríamos concebir una aplicación como un conjunto de componentes de software interrelacionados. Todos estos componentes están construidos bajo las mismas o diferentes tecnologías. Estos componentes pueden correr sobre la misma máquina en un mismo sistema operativo y sobre una misma plataforma o en diferentes procesos, diferentes máquinas con diferentes plataformas y sistemas operativos.  Sin embargo si una aplicación es organizada de esta manera se requiere una forma de crear los componentes y un mecanismo para describir cómo los componentes trabajan juntos.</p><p class="Textbody">Service Component Architecture (SCA) define un enfoque general para realizar estas dos cosas. SCA es un estándar de OASIS originalmente creado por diferentes vendedores como BEA, IBM, Oracle, SAP, etc. La especificación SCA define como crear un componente y como estos componentes interactúan para formar una aplicación. Los componentes en SCA pueden ser construidos en Java o en otros lenguajes y además permite interactuar con otras tecnologías como JEE, Spring o BPEL<span class="Refdenotaalpie" />. SCA define un mecanismo común de ensamblaje que indica como los componentes son combinados dentro de la aplicación. </p><p class="Textbody">SCA es una especificación; existen varias implementaciones entre las que podemos contar Apache Tuscany y Fabric3.  </p><h3 class="Heading3"><a name="Componente" />Componente</h3><p class="Textbody"> </p><p class="Textbody">Una Aplicación puede ser construida con diferentes componentes. En una aplicación simple podríamos definir un componente como un simple objeto corriendo en un proceso. Y en una aplicación compleja podríamos definir un componente como un objeto que corre en varias máquinas utilizando diferentes mecanismos de comunicación.  </p><p class="Textbody">Los componentes son como los átomos con los cuales una aplicación SCA es creada. Como átomos pueden comportarse de forma diferente y pueden ser ensamblados de forma diferente.  </p><p class="Textbody">En el lenguaje SCA, un componente es una instancia de una implementación que debe ser apropiadamente configurada. La implementación es el código escrito en algún lenguaje y la configuración esta escrita en un archivo en un lenguaje llamado SCDL<span class="Refdenotaalpie" /> en dicho archivo se define los servicios que necesita el componente y los servicios que expone. En teoría un componente puede ser implementado en varias tecnologías y diferentes lenguajes. </p><p class="Textbody">Un componente contiene básicamente propiedades, servicios y referencias. </p><div class="Textbody"><img width="199" height="197" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr4" /></div><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody">Cada componente típicamente implementa lógica de negocio exponiendo dicha funcionalidad por medio de uno o varios servicios. Los servicios son descriptos de diferente manera dependiendo de la tecnología que fue implementando el componente por ejemplo si utilizamos java, el servicio será descripto por medio de una interfaz java.  </p><p class="Textbody">Cada referencia que contiene un componente es una interfaz que contiene métodos que el puede invocar. Es decir un componente referencia una definición (una interfaz en java) y no a una implementación; esto permite mayor desacoplamiento y le da el control a SCA para que provea al componente las implantaciones que necesita.  </p><p class="Textbody">Es común la idea de presentar lo que un objeto puede proporcionar por medio de una definición que describe la funcionalidad implementada en objetos. Esto trae muchas ventajas:  </p><ul style="margin-left:1.25cm;"><li class="P82" style="margin-left:0cm;"><p class="P82" style="margin-left:0.25cm;">Desacoplamiento: dado que los objetos no conocen la implementación, es más fácil reemplazar una implementación. </p></li><li class="P82" style="margin-left:0cm;"><p class="P82" style="margin-left:0.25cm;">Inyección de dependencias<span class="Refdenotaalpie" />: permite darle la responsabilidad de creación de los objetos al contenedor de objetos en este caso SCA. Esto es sumamente útil ya que en el caso de SCA, el contenedor puede instanciar o hacer referencia a objetos que no se encuentra en el mismo equipo o si, sin que el programador necesite escribir código de comunicación. SCA inyecta las dependencias de los objetos sin importar donde se encuentran y en que lenguaje fueron escrito. </p></li></ul><p class="Textbody">Además de componentes y referencias, un componente puede definir una o más propiedades. Cada propiedad contiene un valor que puede ser leído del archivo de configuración SCDL cuando el componente es instanciado.  </p><p class="Textbody" /><h3 class="Heading3"><a name="Vinculaciones" />Vinculaciones</h3><p class="Textbody"> </p><p class="Textbody">Los servicios y las referencias permiten a un componente comunicarse, pero no describen como sucede esta comunicación, este es el trabajo de las vinculaciones (en Inglés Bindings).  </p><p class="Textbody">Una aplicación se comunica con diferentes aplicaciones por diferentes protocolos y diferentes modelos de comunicación. </p><div class="Textbody"><img width="291" height="236" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr5" /></div><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody">SCA encapsula la comunicación con diferentes protocolos por medio de las vinculaciones. De esta forma el desarrollador no necesita aprender diferentes protocolos y Apis. Existe una vinculación que puede resolver la comunicación con una tecnología. De este modo existe una vinculación para Web services soap, vinculación para JMS<span class="Refdenotaalpie" />, para comunicación con EJB<span class="Refdenotaalpie" />, etc.</p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><div class="Textbody"><img width="344" height="293" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr4" /></div><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody">Una vinculación especifica como debe ser la comunicación entre un componente SCA y algo más. Dependiendo de la comunicación se debe o no especificar la vinculación, en el caso en que componentes del mismo dominio se comuniquen no es necesario especificar una vinculación; el runtime determina que vinculación utilizar.  </p><p class="Textbody">En el caso de la comunicación sea con un componente SCA de otro dominio u otra aplicación no SCA es necesario definir una o más a vinculaciones para esta comunicación. Cada vinculación define un particular protocolo que puede ser usado en la comunicación con esta referencia o servicio. Una referencia o servicio puede tener múltiples vinculaciones permitiendo comunicarse con diferentes software remoto por diferentes caminos. </p><p class="Textbody">La ventaja que conlleva separar la lógica del negocio plasmada en el componente de su forma de comunicarse (vinculaciones) son mayor flexibilidad y facilidad de diseño y desarrollo.  </p><p class="Standard"> </p><h3 class="Heading3"><a name="La_composici_C3_B3n" />La composición</h3><p class="Textbody"> </p><p class="Textbody">Si el componente es un átomo para SCA, la composición es una molécula. Una composición es un grupo de componentes combinado de forma útil, y además puede ser combinado de diferentes formas.  </p><p class="Textbody">La composición es la base de la promesa más apasionante de una SOA: la agilidad. Una vez que se cuenta con un buen número de servicios, la creación de nuevas funcionalidades útiles para el negocio es sólo cuestión de conectar los servicios adecuados. </p><p class="Textbody">En la práctica, la composición requiere contar con el conjunto adecuado de servicios, y que definan el conjunto de operaciones adecuadas. Además, la tecnología empleada para componer funcionalidades con estos servicios debe estar impulsada desde una perspectiva puramente de negocio para permitir hacer cambios rápidos en las aplicaciones. </p><p class="Textbody">Un compuesto podríamos definirlo como una construcción lógica que genera funcionalidad a partir de servicios expuestos por otros componentes y a la vez es capaz de exponer esta nueva funcionalidad como servicio.  </p><p class="Textbody">Podemos ver un compuesto como lo muestra el siguiente ejemplo: </p><div class="Textbody"><img width="585" height="177" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr4" /></div><p class="Textbody"><span class="T30">Los componentes que forman un compuesto se pueden ejecutar en un solo proceso en un único equipo o </span>distribuidos a través de múltiples procesos en varios equipos. <span class="T30">Una aplicación completa podría ser </span>construida a partir de un solo compuesto, como en el ejemplo que se muestra, o combinar varios compuestos. Los componentes que conforman un compuesto podrían utilizar la misma tecnología, o puede que sea construida utilizando diferentes tecnologías de diferentes plataformas.</p><h3 class="P47"><a name="Cables_y_promoci_C3_B3n." />Cables y promoción. </h3><p class="Standard"> </p><p class="Textbody">Un cable es una abstracción que representa una relación entre una referencia y un servicio que satisface las necesidades de esa referencia. Una referencia de un componente es conectada a un servicio en otro componente usando un cable.</p><p class="Textbody">Al igual que los componentes exponen servicios, una composición puede exponer uno o más servicios. Los servicios pueden ser implementados por componentes dentro de la composición. La composición puede exponer o <span class="T11">promocionar</span> este servicio el cual es expuesto por el componente dentro de la composición. </p><h3 class="P49"><a name="Dominios" />Dominios </h3><p class="Standard"> </p><p class="Textbody">Los Dominios son un concepto importante en SCA. Dado que SCA define un sistema distribuido pero no define como los componentes interactúan entre si.  </p><p class="Textbody">Un dominio puede contener compuestos que pueden contener componentes los cuales puedes ser ejecutados en uno o más procesos en una o más computadoras. </p><div class="P27"><img width="506" height="579" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr6" />        </div><p class="P27">        SCA no define cómo los componentes en las aplicaciones interactúan con diferentes dominios. SCA define el dominio de la aplicación donde los componentes y composiciones se realizan e interactúan. Esto permite que el contenedor de componentes y composiciones pueda hacer optimizaciones útiles.  La vida de un desarrollador de SCA es mucho más sencilla dentro de un dominio, por ejemplo, se pueden evitar las complejidades inherentes a la configuración de aplicaciones de múltiples proveedores o protocolos, descansando en el contenedor SCA. </p><p class="Textbody">Cuando queremos comunicar diferentes dominios de diferentes proveedores lo podemos hacer con protocolos estándar como por ejemplo web services SOAP. Esto lo podemos realizar con vinculaciones. Las vinculaciones nos permiten hablar con diferentes dominios SCA o con otras aplicaciones no SCA.</p><div class="P27"><img width="473" height="642" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr7" />        Un Componente además de proporcionar servicios a sus propios clientes, también puede proveer sus servicios a otros componentes de su dominio y a clientes de otros dominios. </div><h3 class="Heading3"><a name="Usando_pol_C3_ADticas" />Usando políticas</h3><p class="Standard"> </p><p class="Textbody">La interacción entre aplicaciones puede volverse complicada. La especificación política hace más fácil la interacción. SCA define un framework de políticas.  </p><p class="Textbody">Este framework define dos categorías de políticas: </p><ul style="margin-left:1.25cm;"><li class="P83" style="margin-left:0cm;"><p class="P83" style="margin-left:0.25cm;">Políticas de interacción: Modifica como un componente interactúa con otro. Son normalmente aplicadas a las vinculaciones. </p></li><li class="P83" style="margin-left:0cm;"><p class="P83" style="margin-left:0.25cm;">Políticas de implementación: Modifica como un componente se comporta localmente. Estas políticas indican por ejemplo, si un componente debe correr sobre una transacción.</p></li></ul><p class="Textbody">SCA no define como las políticas deben ser descritas dentro de un dominio, cada vendedor es libre de implementar esto. Las políticas son definidas a nivel de dominio, es posible que las exigencias de la política a veces puedan influir en los límites del dominio. Entre dominios, en cambio, SCA no tiene como aplicar las políticas, no hay control. Por lo tanto es conveniente que la comunicación sea basada en web services, para que las políticas puedan ser implementadas mediante ws-policy.   </p><h3 class="Heading3"><a name="SDO__28Service_Data_Objects_29" />SDO (Service Data Objects)</h3><p class="Textbody"> </p><p class="Textbody">“SDO fue diseñado para simplificar y unificar la forma en que las aplicaciones manejan sus datos. Usando SDO las aplicaciones pueden tener acceso uniforme y manipulación de datos desde diferentes recursos de datos, incluyendo base de datos relacionales, XML, web services y información de sistemas empresariales.”<span class="Refdenotaalpie" /> </p><p class="Textbody">Service Data Objects es una tecnología que permite que los datos sean heterogéneos para arquitecturas SOA. La especificación SDO fue desarrollada en 2004 en una colaboración entre BEA, IBM y JCP. En la versión 2.0 fue integrada a la especificación SCA. </p><p class="Textbody">SDO esta basado en el concepto de <span class="Emphasis"><span class="T31">data graphs desconectados. Un data graphs es una estructura de árbol o grafo de objetos. Sobre data graphs desconectados esto significa que un cliente puede recuperar un grafo de objetos de un recurso de datos, modificar los datos y estructura del grafo y luego guardarlo en el recurso de datos.</span></span></p><p class="Textbody"><span class="Emphasis"><span class="T31">La tarea de conectarse a un recurso de datos es </span></span><span class="Emphasis"><span class="T32">más eficiente si s</span></span><span class="Emphasis"><span class="T31">e utiliza un servicio de mediación de datos. Las aplicaciones clientes consultan un servicio mediador de datos y obtienen el grafo de objetos como resultado. Luego la aplicación cliente envía un grafo de datos modificado y el mediador de dato aplicará los cambios al recurso de datos. Esta arquitectura es ideal principalmente con grafos de datos u objetos.</span></span></p><p class="Textbody">SDO permite trabajar con lengu<span class="T56">ajes fuertemente tipados y débilmente tipados.</span><span class="T56"> </span>Esto permite un modelo de programación simple, sin sacrificar el modelo dinámico que necesitan las herramientas y frameworks.</p><p class="Textbody"> SDO también provee una API de metadatos, la cual permite a las aplicaciones, herramientas y frameworks explorar el modelo de datos de un grafo de datos. La API de metadatos no es específica para un rec<span class="T56">urso de datos sino que puede utilizar de forma heterogénea recursos de datos de una forma uniforme.  </span></p><p class="Textbody">Resumiendo las características de SDO podríamos enumerar:  </p><ul style="margin-left:1.25cm;"><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Acceso uniforme a datos de fuentes heterogéneas: XML, RDB, POJO, SOAP, LDAP, JCA, etc. </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Soporta modelo desconectado.  </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Provee ambos estilos de programación: Estático, Dinámico. </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Provee introspección a Metadata. Ejemplo: para acceso a los tipos de datos. </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Es neutral con el lenguaje de programación. Soporte a Java, PHP, C++, etc. </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Reemplaza los diferentes APIs que existen para el acceso a los Datos. </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Libera al desarrollador de los detalles técnicos del backend de los Datos. </p></li><li class="P84" style="margin-left:0cm;"><p class="P84" style="margin-left:0.25cm;">Define una forma única y simple de acceso a fuentes heterogéneas de Datos. </p></li></ul><p class="Standard"> </p><h2 class="Heading2"><a name="Resumen" />Resumen</h2><p class="Textbody"> </p><p class="Textbody">En el desarrollo teórico explicamos conceptualmente SOA, los servicios y el gobierno SOA. Se describieron las herramientas SOA más utilizadas. Para luego centrarnos en el desarrollo SOA, con SCA. En el desarrollo de los temas se puede notar que hay funcionalidad replicada en las herramientas del Gobierno SOA y en SCA. Es necesario recordar que para diseñar SOA no es obligatorio tener todas las herramientas descriptas anteriormente, solo se deben utilizar las que se necesitan. Por ejemplo el registro es necesario siempre, dado que es imprescindible para no tener comportamiento replicado. Pero si se desarrolla con SCA, no es necesario utilizar la funcionalidad de adaptador de un ESB.  </p><p class="Textbody">Por estas razones es importante que el arquitecto SOA, analice los requerimientos y utilice las herramientas justas para sus requerimientos. No es bueno utilizar herramientas solo <span class="T56">porque existen. El objetivo es el beneficio y</span> valor agregado que pueden dar estas herramientas. </p><p class="Textbody">Luego de haber visto las principales herramientas SOA y la forma en la cual podemos desarrollar nuestra SOA, nos centraremos en un caso práctico el cual nos permitirá explicar que se puede desarrollar Web 2.0 con herramientas Open Sources. Además analizaremos las ventajas y desventajas que esto trae el desarrollo Web 2.0 con SOA.  </p><p class="Textbody">Elegiremos qué herramienta de gobierno SOA necesitamos para desarrollar y qué modelo de desarrollo nos conviene utilizar. Además buscaremos en el mercado cual es la herramienta Open Source más utilizada y conveniente para nuestras necesidades. </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><h1 class="P50"><a name="Caso_de_estudio__3A_blog32Un_blog_2C_o_en_espa_C3_B1ol_tambi_C3_A9n_una_bit_C3_A1cora_2C_es_un_sitio_web_peri_C3_B3dicamente_actualizado_que_recopila_cronol_C3_B3gicamente_textos_o_art_C3_ADculos_de_uno_o_varios_autores_2C_apareciendo_primero_el_m_C3_A1s_reciente_2C_donde_el_autor_conserva_siempre_la_libertad_de_dejar_publicado_lo_que_crea_pertinente." />Caso de estudio : blog</h1><p class="Standard"> </p><p class="P36">Esta Tesis trae como objetivo, implementar la Arquitecturas de Software Orientadas a Servicios en la Web 2.0, basándose en herramientas Open Source. Para esto nos valdremos de un ejemplo práctico. Un Weblog es una aplicación simple que refleja el poder de la web 2.0. La comunidad publica (postea) conocimiento, pensamientos, fotos, historias, etc. y los seguidores pueden leer las publicaciones y comentarlas.  </p><p class="P36">Los blogs son un ejemplo claro de la web 2.0 dado que:  </p><ul style="margin-left:1.25cm;"><li class="P72" style="margin-left:0cm;"><p class="P72" style="margin-left:0.25cm;">Permiten sociabilizar y intercambiar conocimiento. </p></li><li class="P72" style="margin-left:0cm;"><p class="P72" style="margin-left:0.25cm;">Dan facilidad de navegación con funcionalidad ajax. </p></li><li class="P72" style="margin-left:0cm;"><p class="P72" style="margin-left:0.25cm;">Permiten comunicarse con diferentes sitios webs. </p></li></ul><p class="P36">Por lo tanto tomaremos como ejemplo el desarrollo de un motor de blogs simple y probaremos que se puede desarrollar con tecnología SOA Open Sources y se analizaran ventajas y desventajas. </p><p class="P36">Cuando se analiza la aplicación de un estilo arquitectónico es esencial que nos centremos en los requerimientos no funcionales, sin olvidar los funcionales.  </p><p class="P36"><span class="T34">Los requerimientos no funcionales especifican propiedades del sistema como restricciones de ambiente y desarrollo, performance, dependencias de plataformas, mantenibilidad y confiabilidad. </span><span class="T35">Estos requisitos, en lugar de definir lo que la aplicación hace, definen cómo la aplicación proporciona las funcionalidades requeridas. </span><span class="T34">Además son el velocímetro para medir la aplicación de un estilo arquitectónico. </span></p><p class="P36">Los requerimientos funcionales por lo general son discretos en el sentido de que agregando o modificando algunas líneas de código en unos pocos lugares es suficiente para implementarlos, mientras que los requerimientos no funcionales son, por lo común, <span class="T27">transversales</span> en el sentido de que es necesario agregar o modificar código en todas partes para implementarlos. En consecuencia no prever un requerimiento no funcional suele ser mucho más costoso que no tener en cuenta un requisito funcional. </p><h2 class="P51"><a name="_C2_BFPor_que_elegir_SOA_para_el_desarrollo_Web_2.0_3F" />¿Por que elegir SOA para el desarrollo Web 2.0?</h2><p class="Standard"> </p><p class="Textbody">Las ventajas de un desarrollo SOA son los mismos para una aplicación Empresarial como para una aplicación Web 2.0. Pero los requerimientos no funcionales de estas aplicaciones son diferentes.  </p><p class="Textbody">Veamos los requerimientos no funcionales de una Web 2.0 : </p><ul style="margin-left:1.25cm;"><li class="P85" style="margin-left:0cm;"><p class="P85" style="margin-left:0.25cm;">Capacidad de escalar: Una características de las Web 2.0 es su rápido crecimiento, por lo tanto es imprescindible que pueda rápidamente escalar a varios servidores de una forma distribuida.  </p></li><li class="P85" style="margin-left:0cm;"><p class="P85" style="margin-left:0.25cm;">Performance: una aplicación web 2.0 debe ser rápida, nunca debe dar sensación de pesadez o lentitud. Esto se logra mediante técnicas de ajax que permiten que la pagina se cargue por sectores mostrando al usuario sectores más livianos y luego los más pesados.  </p></li><li class="P85" style="margin-left:0cm;"><p class="P85" style="margin-left:0.25cm;">Mantenibilidad: si bien todas las aplicaciones deben ser mantenibles, las aplicaciones Web 2.0 están en contante evolución incorporando cada vez más funcionalidad por lo tanto es importante que el código sea claro, simple, fácil de mantener y no debe haber código duplicado.  </p></li><li class="P85" style="margin-left:0cm;"><p class="P85" style="margin-left:0.25cm;">Facilidad de uso: la usabilidad es un tema prioritario en estas paginas, dado que contaremos con todo tipos de usuarios. </p></li><li class="P85" style="margin-left:0cm;"><p class="P85" style="margin-left:0.25cm;">Soporte los navegadores más usados: las paginas web 2.0 deben tener en cuenta los navegadores más utilizados para poder usado por diferentes  usuarios que usan diferentes sistemas operativos y dispositivos.</p></li><li class="P85" style="margin-left:0cm;"><p class="P85" style="margin-left:0.25cm;">Comunicación con otras paginas: las paginas web 2.0 buscan ampliar su mercado y estar en todas partes, por ejemplo publicando un post en Bloogler se ve reflejado en Google Buzz.  </p></li></ul><p class="Textbody">Estos son los los requerimientos genéricos de una web 2.0 ahora veamos como SOA nos ayuda con ellos: </p><ul style="margin-left:1.25cm;"><li class="P86" style="margin-left:0cm;"><p class="P86" style="margin-left:0.25cm;">Capacidad de escalar: La arquitectura SOA es una arquitectura distribuida lo que nos permite tener nuestra aplicación corriendo en diferentes ordenadores con diferentes plataformas.  </p></li><li class="P86" style="margin-left:0cm;"><p class="P86" style="margin-left:0.25cm;">Performance: En este requerimiento SOA no nos ayuda, dado que al agregar más capas desde la base de datos al navegador el proceso de transporte de datos es más lento. La aplicación debe serializar datos en SOAP por ejemplo y el cliente luego debe desserializarlos, para poder utilizarlos. Pero al permitir correr diferentes servicios en diferentes maquinas, es posible disminuir la lentitud agregando más servidores y cargando la web con técnicas de ajax.</p></li><li class="P86" style="margin-left:0cm;"><p class="P86" style="margin-left:0.25cm;">Mantenibilidad: SOA nos ayuda a desarrollar código más claro y reutilizable. SCA en especial es una especificación que promueve las mejores prácticas de desarrollo. Si desarrollamos siguiendo SCA obtendremos alta reutilización de código distribuido.  </p></li><li class="P86" style="margin-left:0cm;"><p class="P86" style="margin-left:0.25cm;">Comunicación con otras paginas: SOA promueve la comunicación y facilita la misma. Utilizando SCA por ejemplo podríamos utilizar servicios web o ser referenciados en diferentes protocolos y métodos de comunicación sin tener que escribir una sola linea de código para realizar esta comunicación.   </p></li></ul><p class="Textbody">Para los requerimientos “Facilidad de uso” y “Soporte de los navegadores más usados” el uso de SOA no aporta nada, es indistinto si se usa o no SOA ya que son requerimientos solo de la capa de presentación de la aplicación. </p><p class="Textbody">En conclusión utilizar una arquitectura SOA nos proporciona mayores ventajas en el momento de desarrollar aplicaciones web 2.0, sin embargo recordemos que como desventaja se veía disminuida la performance. Esto no es un dato menor dado que es importante para la web 2.0 la performance y la agilidad del sitio. El modelo de desarrollo SOA, promueve la reutilización de servicios y la separación en capas, agregando complejidad que afecta la performance.    </p><p class="Textbody">Gracias a técnicas de Ajax y la capacidad de crecer verticalmente, la performance no debería disminuir de forma significativa. Las técnicas de ajax del lado cliente darán al usuario una sensación de agilidad y recargaran la pagina de forma progresiva. La capacitad de crecer verticalmente que nos brinda la arquitectura SOA, nos permite agregar servidores para que se procese parte de nuestra aplicación mucho más rápido.  </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFPorque_optar_por_soluciones_Open_Sources_3F" />¿Porque optar por soluciones Open Sources?</h2><p class="Textbody"> </p><p class="Textbody">Como principal ventaja del software Open Sources se pensaría en el bajo costo dado que se relaciona Open Sources como gratis y esto no es así. Es un error pensar en el Open Sources como una solución barata dado que el software puede tener costo (en nuestro caso no es así, todos los frameworks son open sources y gratuitos) , pero además el software tanto Open Sources como propietario tiene costos ocultos. Como costo oculto podríamos nombrar la falta de soporte, o falta de documentación. Estos costos ocultos hay que tenerlos en cuenta a la hora de optar por un software.</p><p class="Textbody">El uso de frameworks open sources para el desarrollo de aplicaciones trae aparejado muchos beneficios que dependen de la comunidad que respalde el framework; cuanto mayor es la comunidad mayor va a ser el soporte, la documentación, calidad y los usuarios que usan el framework:  </p><ul style="margin-left:1.25cm;"><li class="P87" style="margin-left:0cm;"><p class="P87" style="margin-left:0.25cm;">Soporte: <span class="T56">El soporte brindado puede ser mayor a una aplicación propietaria y la información suministrada por foros de problemas es basta.</span></p></li><li class="P87" style="margin-left:0cm;"><p class="P87" style="margin-left:0.25cm;">Documentación: Si bien no es común que un software open source este bien documentado, la información suministrada por blogs, foros, libros es mayor  en muchos casos que la de productos comerciales. </p></li></ul><p class="Textbody">A la vez existen beneficios intrínsecos del software open source: </p><ul style="margin-left:1.25cm;"><li class="P88" style="margin-left:0cm;"><p class="P88" style="margin-left:0.25cm;">Libertad de uso: podemos usar el programa sin ninguna restricción y además podemos modificar el software y poder comercializar estas mejoras siempre y cuando brindemos usemos la misma licencia.  </p></li><li class="P88" style="margin-left:0cm;"><p class="P88" style="margin-left:0.25cm;">Libertad de aprender: podemos aprender del código fuente, aprender como fue hecho el framework y saber como realmente funciona. De esta forma el grupo de trabajo no esta limitada a ver solo la documentación sino que puede debugear el código fuente y palpar lo que hace realmente. </p></li><li class="P88" style="margin-left:0cm;"><p class="P88" style="margin-left:0.25cm;">Libertad de modificar: Si existe un bug, es posible corregirlo y publicar su corrección para que se encuentre en futuras versiones. Además podemos extender el framework como queramos, desarrollando nueva funcionalidad que luego podemos publicar para que la comunidad la pruebe y use.  </p></li></ul><p class="Textbody">Estas ventajas no son menores, dado que el conocimiento es el arma más importante en un grupo de desarrollo informático y el open source permite cultivar el conocimiento, dando nos el privilegio de leer las lineas de código y ver como funciona.  </p><p class="Textbody">Apostar a el software open source es apostar al capital humano, con un grupo consolidado puede aprender y desarrollar mejor a partir del código fuente. Los desarrolladores aprenden como funciona el framework viéndolo funcionar.  </p><p class="P37">Como desventaja se ve que al estar el código disponible, puede haber mayores problemas de seguridad, ya que cualquier programador con malas intenciones puede buscar fácilmente bugs o debilidades que pueda explotar para su propio beneficio. </p><p class="Textbody">Estos beneficios son propios del Open Source, y además existen razones para pensar en desarrollar SOA Open Sources:</p><ul style="margin-left:1.25cm;"><li class="P89" style="margin-left:0cm;"><p class="P89" style="margin-left:0.25cm;">Amplia variedad de herramientas en el mercado: La variedad de propuesta para herramientas SOA es grande y en algunos casos mayor al abanico de opciones de software comercial. </p></li><li class="P89" style="margin-left:0cm;"><p class="P89" style="margin-left:0.25cm;">Amplio uso y aceptación: Las herramientas open source SOA son usadas por importantes empresas  y con una gran comunidad.</p></li></ul><p class="Textbody">Dado estos beneficios es muy importante utilizar herramientas open source en desarrollos SOA. Utilizar estas herramientas no solo beneficia a quien lo usa sino a toda una comunidad.  </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFQue_plataforma_utilizar_3F" />¿Que plataforma utilizar?</h2><p class="Textbody"> </p><p class="Textbody">Si decidimos utilizar tecnología Open Source para el desarrollo, la opción más clara es utilizar la plataforma Java ya que cuenta con la más amplio abanico de herramientas SOA. La comunidad Java fue vanguardista con respecto a SOA. En java están escritos la mayor cantidad de framework SOA open source y los más utilizados.  </p><p class="Textbody">Otra opción es utilizar la plataforma .NET la cual provee herramientas SOA, las cuales en su gran mayoría son propietarias. Además la comunidad open sources de .NET es mucho menor a la de Java. Por esta razón descartamos .NET.  </p><p class="Textbody">Otras plataformas open sources pueden ser interesantes para desarrollar, PHP, Ruby o Python, son muy relevantes para el mundo web, pero no para el mundo SOA. Si bien existe soporte y herramientas SOA en estas plataformas, es mucho menor que el del  mundo Java.</p><p class="Textbody">La plataforma Java fue acompañada por grandes proveedores de software como IBM, BEA, Oracle, Sun (en su momento)  para convertirse en la plataforma ideal para desarrollar SOA. Dados la condición de Java en el mercado es muy conveniente utilizarlo para nuestro desarrollo. </p><p class="Textbody"> </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFQue_herramientas_necesitamos_en_nuestro_desarrollo_3F" />¿Que herramientas necesitamos en nuestro desarrollo?</h2><p class="Textbody"> </p><p class="Textbody">Es importante recordar que para desarrollar una arquitectura SOA, no es necesario utilizar todas las herramientas y frameworks que hay en el mercado. Una tarea del arquitecto SOA es revisar los requerimientos y analizar que herramientas son necesarias.  </p><p class="Textbody">Para el desarrollo del motor de blog SOA, va a ser necesario registrar los servicios por lo tanto se debe utilizar un software de registro de servicios. Al registrar los servicios, se crea un repositorio de servicios que sirve para que no se dupliquen y como documentación de los mismos.  </p><p class="Textbody">Existen diferentes herramientas y framework SOA, y entre ellos hay funcionalidad que se solapa. Y a la vez existen diferentes caminos de desarrollo por lo tanto, una decisión que hay que tomar antes de desarrollar, es qué modelo de desarrollo utilizar. Una opción es desarrollar nuestra aplicación utilizando un framework de web services para exponer servicios soap y nuestra aplicación se comunicara con el mundo por medio de un ESB que se encargara de traducir los mensajes a soap. </p><div class="Textbody"> <img width="662" height="241" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr8" />  </div><p class="Textbody"> </p><p class="Textbody">Este enfoque nos obliga a utilizar un ESB para relacionarnos con otras aplicaciones de la web, dado que las demás aplicaciones se comunican y exponen sus servicios de diferente manera.  </p><p class="Textbody">Otro camino posible es desarrollar según el estándar SCA. Usando SCA no necesitamos un ESB para comunicarnos con aplicaciones web ya que SCA prevé esto. Por medio de los vínculos de SCA podemos comunicarnos con diferentes aplicaciones con diferentes protocolos.  </p><div class="Textbody"><img width="580" height="201" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr3" /></div><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody">Podríamos usar un ESB para dos propósitos, unificar el canal de comunicación de todas las aplicaciones de mi empresa y permitir que aplicaciones dialoguen sin importar el  protocolo de comunicación que usen. Como el motor de blog es una única aplicación que se podría publicar en internet o en una intranet, no necesita tener un canal de comunicación unificado. Y si usamos SCA no vamos a necesitar que un ESB haga adaptaciones de protocolo o lenguaje ya que SCA provee esta funcionalidad. </p><p class="Textbody">Usar SCA sin un ESB es la mejor opción para el desarrollo del motor del blog. SCA nos provee la posibilidad de comunicarnos con cualquier aplicación sin importar la técnica de comunicación que use y además nos provee un modelo de desarrollo facilitando la mantenibilidad, agilidad de desarrollo y un modelo de desarrollo distribuido. </p><p class="Textbody">Una funcionalidad interesante a introducir en el blog es poder marcar workflows configurables en diferentes situaciones por ejemplo que cuando publicamos un post, que se publique el post y avise a todos los seguidores del blog por mail o al comentar un post, se guarde el comentario y se envié por mail a el dueño del blog una notificación.  Para realizar esta funcionalidad y que sea realmente configurable es conveniente usar un motor BPEL. </p><p class="Textbody">En resumen: </p><ul style="margin-left:1.25cm;"><li class="P90" style="margin-left:0cm;"><p class="P90" style="margin-left:0.25cm;">Para el desarrollo es más conveniente el uso de la especificación SCA. </p></li><li class="P90" style="margin-left:0cm;"><p class="P90" style="margin-left:0.25cm;">Para el Gobierno SOA solo necesitamos una herramienta de registro y un motor BPEL, no es necesario ni un ESB, ni ESP y CEP (dado que no tenemos procesamiento complejo de eventos) , ni EIA (dado que no contamos con aplicaciones heredadas o legacy).  </p></li></ul><p class="Textbody">A continuación se analiza que herramientas open source que nos provee el mercado para desarrollar el motor de blog. </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFQue_implementaci_C3_B3n_SCA_utilizar_3F" />¿Que implementación SCA utilizar?</h2><p class="Textbody"> </p><p class="Textbody">Existen actualmente varias implementaciones open source de la especificación SCA de la cuales se destaca: Apache Tuscany y Fabric3. Apache Tuscany es implementación de referencia de SCA. Su comunidad es mayor a la de Fabri3. Los sitios web de Tuscany y OASIS han recogido de forma colaborativa documentación extensa. Los documentos de la especificación de SCA y su tecnología relacionada están bien documentadas y son perfectamente entendibles.  </p><p class="Textbody">Apache Tuscany dio a luz su primera versión beta en el año 2006, su versión a en este momento es 1.6 (versión publicada en febrero del 2010). Tuscany presenta un desarrollo sostenido y rápida corrección de errores.  </p><p class="Textbody">Considerando los puntos: comunidad, documentación y estabilidad, podemos afirmar que Apache Tuscany es la mejor opción como solución SCA.   </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFQue_herramienta_de_registro_utilizar_3F" />¿Que herramienta de registro utilizar?</h2><p class="Textbody"> </p><p class="Textbody">El objetivo de tener un registro de las funcionalidades desarrolladas es que todos los desarrolladores conozcan las funcionalidades y no exista duplicidad de servicios. Para esto se podría utilizar diferentes herramientas de propósito más general, como una wiki o una base LDAP, pero es mejor utilizar una herramienta de propósito particular. En el mercado existen herramientas open source para el registro de servicios. Entre los más importantes podemos mencionar a MuleSource Galaxy y Registro de WSO2. </p><p class="Textbody"><span class="T11">MuleSource Galaxy</span>: Esta basado en un diseñador de repositorios para la gestión de artefactos de software basados en SOA. Entre ellos se incluye la configuración del ESB Mule, WSDL, archivos xml y configuración de Spring. Es una perfecta herramienta de registro cuando se utiliza ESB mule ya que se integra totalmente con ese producto.</p><p class="Textbody"><span class="T11">Registro de WSO2</span>: Esta diseñado para almacenar, catalogar, indexar y gestionar metadatos de empresa relacionados con artefactos SOA. Incluye el control de versiones y su rapidez lo hace un buen candidato para sistemas empotrados.</p><p class="Textbody">El producto Galaxy tiene soporte para las mismas funcionalidades generales que el registro de WSO2, como puede ser la categorización de recursos, la monitorización y la gestión de ciclo de vida y de la dependencia. Además, su versión 1.5 incluye nuevas funcionalidades como la replicación (disponible solo la versión de pago) tiene soporte para scritps y una API de eventos.</p><p class="Textbody">El producto de registro WSO2 es muy sencillo de utilizar y en este punto supera a Galaxy gracias a su mejor infraestructura para Atom/Rss y sus funcionalidades de control de versiones y de restauración de versiones anteriores.  </p><p class="Textbody">Las funcionalidades más atractivas de Galaxy se encuentran en la versión de pago mientras que la herramienta de registro de WSO2 es 100% libre y gratuita. Por esta razón y la facilidad de uso, optamos por la herramienta de registro de WSO2. </p><p class="Textbody"> </p><h2 class="Heading2"><a name="_C2_BFQue_herramienta_BPM_utilizar_3F" />¿Que herramienta BPM utilizar?</h2><p class="Textbody"> </p><p class="Textbody">Como dijimos anteriormente el blog va tener funcionalidad de workflow, permitiendo que el blog se adapte a diferentes realidades como por ejemplo: uso empresarial en una intranet o un blog personal en la web. Utilizar BPEL nos permitirá hacer una aplicación más genérica y configurable.  </p><p class="Textbody">En el mercado existen gran variedad de herramientas BPM y BPEL open source, las más importantes son: </p><ul style="margin-left:1.25cm;"><li class="P91" style="margin-left:0cm;"><p class="P91" style="margin-left:0.25cm;"><span class="T11">Intalio BPM (edición community)</span> : Herramienta BPM rica en funcionalidades que utiliza la noción de modelado de procesos de negocio BPMN para generar orquestaciones basadas en BPEL. Al ser una versión open source de un producto comercial utiliza librerías de la versión de pago, este software fue concebido para permitir  el desarrollo y luego cuando se ponga en producción se compre la versión estándar. </p></li><li class="P91" style="margin-left:0cm;"><p class="P91" style="margin-left:0.25cm;"><span class="T11">Motor ActiveBPEL</span>: Motor BPEL eficiente y sumamente cuidado. Los modelos pueden diseñarse utilizando su herramienta Designer que es gratuita pero no es open source. La funcionalidad más importante, como puede ser las instancias de procesos persistentes a una base de datos o el control de versión de los procesos, únicamente esta disponible en  la versión Enterprise. </p></li><li class="P91" style="margin-left:0cm;"><p class="P91" style="margin-left:0.25cm;"><span class="T11">Apache ODE</span>: Apache ODE (Orchestation Director Engine) es un motor BPEL de ejecución de procesos. Su API permite extenderlo de muchas maneras y por lo tanto, no esta limitado a utilizar únicamente SOAP. Es un motor liviano que puede integrarse fácilmente con productos de Apache como Service Mix. Apache ODE no posee editor gráfico para deseñar los procesos pero se puede contar con un plugin que se puede instalar en Eclipse. </p></li><li class="P91" style="margin-left:0cm;"><p class="P91" style="margin-left:0.25cm;"><span class="T11">Jboss JBPM</span>: Es un motor de workflow maduro, eficiente y ligero que va siempre  de la mano de la herramienta de modelado basado en Eclipse. Usa su propio lenguaje de grafo en xml llamado jPDL  (jBPM process Definition Language) y tiene soporte para todos los nodos de modelado principales, como puede ser las decisiones y las bifurcaciones. Se puede extender de manera sencilla y no está restringido su uso a ningún entorno de despliegue. A diferencia de otras alternativas, no existe una actualización a la versión comercial y no hay ninguna funcionalidad que esté restringida.</p></li><li class="P91" style="margin-left:0cm;"><p class="P91" style="margin-left:0.25cm;"><span class="T11">ObjectWeb Bonita</span>: Se trata de un motor de workflow potente y compatible con XPDL. Es un proyecto maduro y bien documentado. Incluye excelente integración con herramientas gráficas de actividades humanas (por ejemplo, un generador de formularios) No dispone de ningún editor de software libre y necesita el servidor de aplicaciones JOnAS (Java Open Application Server) </p></li><li class="P91" style="margin-left:0cm;"><p class="P91" style="margin-left:0.25cm;"><span class="T11">WSO2 Bussiness Process Server</span>: El producto está basado en Apache ODE e incluye una interfaz administrativa basada en la Web y funcionalidades de simulación.     </p></li></ul><p class="Textbody">Si buscamos una solución 100% open source y sin restricciones se debe elegir Apache ODE, Jboss JBPM, Bonita o WSO2 Bussiness Process Server. Una restricción importante es que el software que deseamos construir no dependa de un sistema operativo, base de datos o servidor. Bonita depende del servidor JOnAS por lo tanto lo eliminamos como opción. Si analizamos la comunidad y la documentación para seleccionar entre WSO2 Bussiness Process Server, Apache ODE y JBPM, el ganador sería JBPM dado que fue uno de los primeros productos BPM open source, su comunidad es bastante grande y activa y la documentación es basta.  </p><p class="Textbody">Jboss JBPM es el producto más maduro y probado en el mercado pero es un producto bpm, que como explicamos anteriormente BPM puede ser usado para la orquestación de servicios web, pero no fue concedido para esto y por lo tanto se debe desarrollar modificaciones para cumplir la funcionalidad de orquestación. En el caso de JBPM, es necesario desarrollar un mecanismo para publicar su funcionalidad como web services. Dado que se quiere minimizar los costos de desarrollo se opta por no eledir JBPM.</p><p class="P39">WSO2 Bussiness Process Server es un motor BPEL de WSO2, empresa centrada en el desarrollo de <span class="T46">open source de soluciones SOA. WSO2 Bussiness Process Server es un desarrollo que toma como Apache ODE de base y le agrega herramientas administrativas las cuales facilitan el desarrollo y la administración del motor BPEL </span></p><p class="P42"><span class="T42">Contamos con todas las h</span>erramientas Open Source para comenzar a desarrollar, en la secciones siguientes especificaremos la arquitectura para luego señalar las herramientas de desarrollo. </p><p class="P42"> </p><h2 class="Heading2"><a name="Desarrollo_de_arquitectura_del_Blog" />Desarrollo de arquitectura del Blog </h2><p class="Textbody"> </p><p class="Textbody">Un requerimiento no funcional importante para motor de blog es que sea capaz de ser usado en diferentes plataformas. El motor de blog debe poder utilizar base de datos de diferentes proveedores y ser lo más flexible posible. De esta forma se podría utilizar en una intranet de una empresa como sistema de blog y comunicación con sus empleados o como un blog común expuesto en internet.  </p><p class="Textbody">Para satisfacer este requerimiento es necesario pensar en una arquitectura modular y por capas donde cada capa se abstraiga y cumpla una responsabilidad propia. La capa de servicios va a ser contenida por un dominio SCA y el cliente podrá ser un cliente que utilice SCA o cualquier otro framework cliente de servicios web. </p><div class="Textbody"><img width="644" height="405" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr9" /></div><p class="Textbody">Es necesario separar la aplicación en dos, una parte servidor y otra cliente de esta forma la aplicación servidor expone los servicios sin importar el consumidor y una aplicación cliente utiliza esos servicios para mostrarlos de forma amigable al usuario final. Se podría utilizar cualquier protocolo para comunicar el servidor con el cliente dado, que sera indistinto a la hora de desarrollar por que se usará un framework SCA. SCA permite un solo servicio con diferentes protocolos de comunicación y end points. Dado que el cliente va a consumir un solo protocolo vamos a optar por publicar servicios basados en SOAP.  </p><p class="Textbody">Al separar la aplicación cliente interfaz de la api servidor podemos tener muchos clientes; se puede desarrollar un cliente de escritorio, un cliente móvil o una pagina web, que permitan realizar todas las acciones propias de un blog.  </p><p class="Textbody">Para que se transmitan objetos livianos es necesario utilizar DTOs (data transfers Objects). Los DTOs son objetos que solo representan los datos que son necesarios mostrar. Esto permite que solo se envién al cliente los datos que necesita y además, no es necesario enviar los  objetos del modelo, que no es recomendado ya que los objetos del modelo tienen lógica del negocio que no es bueno hacer pública y a la vez son más pesados. Los DTOs se van a serializar y van a ser enviados al cliente por medio del protocolo SOAP. Con la separación de los objetos del modelo con los DTOs, se obtiene como ganancia:</p><ul style="margin-left:1.25cm;"><li class="P92" style="margin-left:0cm;"><p class="P92" style="margin-left:0.25cm;">Los DTO utilizan SDO para ser serializados, por lo tanto el modelo negocio es independiente de SDO y de cualquier tecnología, lo que nos permite reutilizarlo o migrar tecnología sin tocar los objetos del modelo de negocio.</p></li><li class="P92" style="margin-left:0cm;"><p class="P92" style="margin-left:0.25cm;">Como dijimos anteriormente los objetos DTOs muestran solo lo que los servicios deben publicar. </p></li><li class="P92" style="margin-left:0cm;"><p class="P92" style="margin-left:0.25cm;">Los DTOs no tienen lógica ni métodos por lo tanto son más livianos.  </p></li></ul><p class="Textbody">La capa de servicio va a estar dentro de nuestro dominio SCA y la aplicación cliente en otro, lo que permite que estas aplicaciones estén desacopladas. La capa de servicio va a utilizar un motor BPEL como ya lo dijimos anteriormente. Para ello va a utilizar la funcionalidad de integración con BPEL de Tuscany.  </p><p class="Textbody">La capa de datos es la encargada de buscar datos a una base de datos, pero no debe depender de un motor de base de datos de algún proveedor por lo tanto es necesario utilizar algún framework que nos permita hacer esto. Frameworks ORM existen muchos en el mercado, pero sin duda el más popular es Hibernate; su reinado en el mundo de los framework ORM es innegable. Con Hibernate podremos hacer la aplicación independiente del motor de base de datos que utilice.</p><p class="Textbody">Vimos la arquitectura a alto nivel, ahora veremos como se compone físicamente la aplicación, con un diagrama de paquetes: </p><p class="Textbody"> </p><p class="Textbody"> </p><div class="Textbody"><img width="743" height="523" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr2" /></div><p class="Textbody"> </p><p class="Textbody">La división de paquetes nos da mayor flexiblilidad y mantenibilidad, dado que tiene como objetivo que se pueda cambiar algún paquete sin cambiar los demás.   </p><p class="Textbody">Hay paquetes que contienen declaraciones y otros la implementación de funcionalidad, esto ayuda al desacoplamiento. De esta forma podemos cambiar el paquete de implementación sin modificar los otros paquetes siempre y cuando no cambie una declaración.  </p><p class="Textbody">Los paquetes son: </p><p class="Textbody"><span class="T11">Common</span>: Contiene clases, declaración de excepciones y declaraciones de tipos comunes a todos los paquetes. Todos los paquetes dependen de este y common no depende de ningún paquete.</p><p class="Textbody"><span class="T11">Model</span>: Contiene la representación lógica del modelo de negocio, modelada en clases. Solo depende de common.</p><p class="Textbody"><span class="T11">Repository</span>: Contiene la declaración de los objetos de acceso a datos. Depende de common y model. </p><p class="Textbody"><span class="T11">Persistent</span>: Contiene la implementación de los objetos de acceso a datos. Depende de common, model y repository. Este paquete contendrá todos los objetos que permiten persistir y recuperar de la base de datos a los objetos del modelo para ello utilizará Hibernate. </p><p class="Textbody"><span class="T11">Dto</span>: Contiene la implementación de los objetos transferencia de datos. Solo depende de common. </p><p class="Textbody"><span class="T11">Service</span>: Contiene la declaración de los servicios. Depende de common y dto.</p><p class="Textbody"><span class="T11">Synchronizer</span>: Contiene la implementación de los objetos encargados de sincronizar los objetos del modelo con los DTOs y viceversa. Depende de common, model, dto, repository y persisten.</p><p class="Textbody"><span class="T11">Service-impl</span>: Contiene la implementación de los servicios. Depende de common, model, dto, repository, persisten, service y synchronizer. En esta capa se expondrán todas las funcionalidades del sistema. </p><p class="Textbody"><span class="T11">Web</span>: Contiene los archivos de SCA, y de configuración general. Depende de common, service, service-impl y dto. Se separa SCA del paquete service-impl para no generar dependencia con el framework Apache Tuscany y también para mayor organización. </p><p class="Textbody">Estos son los paquetes del lado servidor, del lado cliente existe un solo paquete. </p><p class="Textbody"><span class="T11">WebClient</span>: contiene la implementación de los objetos encargados de generar la interfaz gráfica. El cliente no tiene necesidad de utilizar los mismos paquetes de declaración de servicios y dto. Es más el cliente podría estar escrito en otros lenguajes y otras plataformas, pero para acelerar el desarrollo se utilizara los objetos dto ya desarrollados en el proyecto servidor. </p><p class="Textbody">El cliente esta totalmente separado de la aplicación servidor para obtener mayor desacoplamiento y a la vez esto nos permite tener diferentes clientes sin replicar código. Los clientes podrían ser aplicaciones web como la desarrollada en esta tesis, aplicaciones de escritorio, se podría publicar un post usando algún editor de texto (Microsoft word por ejemplo), readers rss, etc. Publicando las funcionalidades en diferentes protocolos permitimos que diferentes clientes puedan usar nuestra aplicación cumpliendo un requisito de la web 2.0 que es que nuestro sitio debe dar la sensación de estar en todas partes. </p><div class="Textbody"><img width="501" height="594" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr10" /></div><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="Textbody"> </p><p class="P27">        </p><p class="P27">        Para comprender como interactúan los diferentes paquetes veamos un diagrama de secuencia de ejemplo :</p><div class="Textbody"><img width="743" height="262" alt="" src="file:///java/proyecto/practica/trunk/nornas/doc/resources/" class="fr3" /></div><p class="Textbody"> </p><p class="Textbody"> </p><p class="P27">        </p><p class="P27">El ejemplo muestra la siguiente secuencia:</p><ul style="margin-left:0cm;"><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">El cliente envía un pedido con datos de una entidad “x” para que se guarden. Lo que envía el cliente es un DTO, esto se envía por un protocolo soportado por SCA, por ejemplo SOAP.  </p></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">El servidor toma este pedido por medio de SCA se desserializa, se envía el DTO al servicio implementado que se encuentra en service-impl. </p></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">El servicio necesita el objeto del modelo para guardar, por lo tanto debe sincronizar los datos  del objeto del modelos con los del DTO, para lo que usa un objeto sincronizador.</p></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">El objeto sincronizador, sincroniza los objetos de la siguiente manera:  </p><ul style="margin-left:1.25cm;"><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">En caso de existir un objeto con el id del DTO lo trae y aplica las modificaciones de datos que se reflejan en el DTO. </p></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">De lo contrario crea el objeto del modelo y lo <span class="T27">popula o puebla</span> con los datos del DTO.</p></li></ul></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">El servicio obtiene el objeto del modelo del proceso de sincronización, para luego permitir que el objeto del modelo ejecute métodos propios de la funcionalidad. </p></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">Luego se llama al objeto encargado de la<span class="T56"> persistencia, este guarda el objeto.</span></p></li><li class="P93" style="margin-left:0cm;"><p class="P93" style="margin-left:0.25cm;">Por ultimo envía al cliente un mensaje, indicando el éxito de la operación. </p></li></ul><p class="Textbody">Dado este esquema de paquetes tenemos una aplicación lo suficiente desacoplada para adaptarse a diferentes realidades y puede utilizarse como medio de comunicación en diferentes ambientes, sobre diferentes plataformas. Antes de terminar de especificar la arquitectura veamos los framework que se utilizaran para beneficiar el desarrollo. </p><h3 class="P48"><a name="Framework_open_source_y_gratuitos" />Framework open source y gratuitos</h3><ul style="margin-left:1.25cm;"><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">SCA</span> : Como se nombro anteriormente se usara como framework SCA Apache Tuscany. </p></li><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">BPEL</span>: WSO2 Bussiness Process Server es un producto basado en Apache ODE que como detallamos anteriormente es la mejor opción BPEL. </p></li><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">ORM</span>: Dado que la aplicación debe poder guardar datos en las bases de datos más utilizadas, y además debemos guardar nuestros objetos en tablas, el mejor camino en este caso es utilizar un ORM, el cual elegimos hibernate, por su madurez y gran comunidad. </p></li><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">Inyección de Dependencias</span>: Spring es un framework que nos facilita el desarrollo, brindando la Inyección de dependencias, la inyección de dependencia permite que obtengamos un objeto por medio de un contexto y en este contexto configuremos las dependencias de este objeto, además Spring facilita el uso de hibernate y facilita el desarrollo de tareas relacionadas con arquitectura por ejemplo seguridad y transaccionalidad. Además se integra fácilmente con Apache Tuscany.</p></li><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">Sincronización</span>: Apache Dozer es un framework que facilita la sincronización de DTO con objetos del modelo.</p></li><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">Framework web</span>: Apache Click es un framework web joven que permite desarrollar interfaces de usuario rápidamente y de forma fácil.</p></li><li class="P96" style="margin-left:0cm;"><p class="P96" style="margin-left:0.25cm;"><span class="T11">Framework javascript</span>: Dado que en necesario utilizar mucho javascript para dar agilidad a el sitio; se utilizara un framework javascript llamado jquery. </p><p class="P99" style="margin-left:0.25cm;"> </p></li></ul><p class="P29">Se utilizan diferentes herramientas open source que nos facilitan el desarrollo: </p><ul style="margin-left:1.25cm;"><li class="P97" style="margin-left:0cm;"><p class="P97" style="margin-left:0.25cm;"><span class="T11">Servidor</span>: Las aplicaciones tanto cliente como servidor necesitan un servidor web, que corra java, existen varios servidores web open source pero sin duda los más importantes son Apache Tomcat y jetty. Por lo tanto la aplicación deberá correr y sera probada en estos dos servidores. Apache tomcat y jetty son usados por servidores de aplicación como JBoss, Apache Geronimo, JOnSA, etc. Por lo tanto la aplicación funcionaria sobre estos servidores. </p></li><li class="P97" style="margin-left:0cm;"><p class="P97" style="margin-left:0.25cm;"><span class="T11">IDE</span>: Como entorno de desarrollo integrado se eligió eclipse, por su agilidad y capacidad de extenderse brindando soporte a todas las actividades del desarrollo.</p></li><li class="P97" style="margin-left:0cm;"><p class="P97" style="margin-left:0.25cm;"><span class="T11">Base de datos</span>: Si bien la aplicación soporta cualquier tipo de base de datos para el desarrollo y  las pruebas tomaremos una de referencia esta sera Postgresql y mysql dado que son las más relevantes en el mundo Open Source.</p></li><li class="P97" style="margin-left:0cm;"><p class="P97" style="margin-left:0.25cm;"><span class="T11">Herramienta de construcción</span>: Apache Maven provee funcionalidad de construir la aplicaciones y brinda un modelo de construcción. Con  maven se puede generar proyectos y  generar el ejecutable de forma fácil.</p></li><li class="P98" style="margin-left:0cm;"><p class="P98" style="margin-left:0.25cm;"><span class="T7">Herramienta de test de los web service</span><span class="T2">: Como herramienta de test de los web service se utilizara un producto llamado SoapUI, el cual se distribuye en dos ediciones una estandar, gratuita y open source (es la que vamos a utilizar) y otra </span><span class="T2">versión empresarial de pago. Los test que tenemos que realizar no son muy complejos por este motivo la  versión estándar es suficiente.</span></p></li></ul><h1 class="P50"><a name="Conclusi_C3_B3n" />Conclusión</h1><p class="P38"> </p><p class="Textbody">El desarrollo del Blog, nos indica que se puede desarrollar aplicaciones completas con un Gobierno SOA con tecnologías abiertas y gratuitas. Existen en el mercado varios frameworks y herramientas SOA Open Source para desarrollar una infraestructura SOA.  Frameworks SCA para el desarrollo de servicios como Apache Tuscany y varios productos para conformar el Gobierno SOA. </p><p class="Textbody">Una arquitectura basada en Open Source, si bien no tiene un respaldo de una empresa, tiene el respaldo de una comunidad. Por este motivo es importante que los productos Open Source tengan una comunidad grande y activa. Cuanto mayor y más activa sea la comunidad, mejor va ser la documentación y la calidad del software  </p><p class="Textbody">El costo de integración de los diferentes productos Open Source es alto; se debe contar con gente capacitada y con espíritu autodidacta, la cual invertirá más tiempo que si se utiliza un producto enlatado. Pero el tiempo que se utiliza para instalar y configurar las diferentes herramientas no es tiempo perdido ya que el conocimiento de la herramienta, de su integración y de su funcionamiento pasan a ser un activo. Para capitalizar este conocimiento es importante que se documente; una buena practica es contar con una wiki en la cual se publican las lecciones aprendidas. Con una cultura que se base en resguardar el conocimiento, las herramientas open source nos dan mayor control y facilidad de uso. </p><p class="Textbody">Existe un abanico importante de diferentes soluciones SOA Open Source que compiten de igual a igual con productos comerciales. Además de una cantidad de importante de documentación y libros. Por estas razones es que el desarrollo SOA Open Source es viable y beneficia a quien lo usa.  </p><p class="Textbody">La web 2.0 sobre una arquitectura SOA brinda varios beneficios, los beneficios propios del uso de SOA: </p><ul style="margin-left:1.25cm;"><li class="P94" style="margin-left:0cm;"><p class="P94" style="margin-left:0.25cm;">No existirán funcionalidades replicada en varios sistemas. </p></li><li class="P94" style="margin-left:0cm;"><p class="P94" style="margin-left:0.25cm;">No existirán funcionalidades o procesos de integración entre sistemas. </p></li><li class="P94" style="margin-left:0cm;"><p class="P94" style="margin-left:0.25cm;">Mayor flexibilidad e integración. </p></li><li class="P94" style="margin-left:0cm;"><p class="P94" style="margin-left:0.25cm;">Bajo acoplamiento. </p></li><li class="P94" style="margin-left:0cm;"><p class="P94" style="margin-left:0.25cm;">Integración basada en estándares. </p></li></ul><p class="Textbody">Y a la vez beneficios propios de su uso en la web 2.0</p><ul style="margin-left:1.25cm;"><li class="P95" style="margin-left:0cm;"><p class="P95" style="margin-left:0.25cm;">Comunicación con otras web de forma fácil y estándar. </p></li><li class="P95" style="margin-left:0cm;"><p class="P95" style="margin-left:0.25cm;">Los sistemas están distribuidos facilitando la escalabilidad. </p></li></ul><p class="Textbody">Como desventaja podemos afirmar que se penaliza la performance dado que se cuenta con sistemas mas segmentados, la comunicación entre ellos lleva mayor tiempo, pero esta desventaja es menor dado que al ser un sistema distribuido la performance se puede aumentar aumentando el numero de servidores. SOA permite crecer de forma horizontal fácilmente, gracias a que es una arquitectura distribuida.  </p><p class="Textbody">Otra desventaja no menor es el costo de desarrollar la web 2.0 con SOA. Las web 2.0 desarrolladas sobre una plataforma SOA son más costosas, dado que llevan más tiempo y mayor costo de hardware en la puesta en marcha del sistema. De todos modos, la inversión es justificada debido las ventajas de la plataforma. Al utilizar software Open Source y gratuito disminuye un poco el costo del proyecto.  </p><p class="Textbody">El modelo de desarrollo SOA propuesto concuerda con los requerimientos no funcionales de una web 2.0, permitiendo desarrollar de forma fácil, un modelo arquitectónico distribuido.  </p><p class="P41">SCA facilita mucho el desarrollo de aplicaciones SOA y la intercomunicación con otros productos. Y a la vez propone las mejores prácticas de programación, nos ayuda mucho a hacer las cosas bien, separando las incumbencias con lo que logramos que el modelo de objetos quede “limpio” y que no “sepa” nada de SOA. Por lo tanto el modelo es independiente de la tecnología de implementación del sistema facilitando la reutilización y posibles migraciones futuras. SCA brinda un modelo de desarrollo desacoplado y flexible. Apache tuscany es muy buena implementación, documentada y segura aunque le falta madurés. Su comunidad es pequeña y el número de usuarios es poco pero tenemos que tener en cuenta que es una tecnología nueva. Apache Tuscany es un producto con mucho futuro y es esperable que su comunidad crezca.  </p><p class="P41">Durante el desarrollo de esta tesis se fue gestando otro modelo arquitectónico llamado W<span class="T62">eb-oriented architecture (WOA). WOA, como SOA, tiene varias definiciones. Algunos ven a WOA como un estilo arquitectónico y un subestilo de SOA basado en aplicaciones web, más liviano que SOA. Otra definición es el uso de REST para construir servicios web usando tecnología web como HTTP y documentos XML. WOA es un estilo </span><span class="T62">arquitectónico que toma las mejores características de SOA y de la Web 2.0. </span><span class="T62">Este enfoque mucho más orientado a la Web es por lo que muchos lo llaman Web-Oriented </span><span class="T62">Architecture (WOA) y se basa en la enorme fuerza de tracción de la World Wide Web en </span><span class="T62">sí y sus fundamentos arquitectónicos subyacentes. Basado en los conceptos básicos y los resultados que han hecho de la Web, la mayor red abierta en el planeta, así como el mayor SOA actualmente en existencia. </span></p><p class="P43">WOA es un modelo ideal para desarrollar SOAs livianas, lo cual encaja muy bien con una Web 2.0. Obteniendo las ventajas de SOA sin sacrificar la performance. Y a la vez es útil para desarrollar SOA empresariales. </p><p class="P43">Sin duda que si se desea desarrollar una web 2.0 es ideal poderlo hacer con WOA, pero este estilo arquitectónico comienza a gestarse por lo que no existen herramientas que lo soporten o framework que faciliten el desarrollo. A las claras WOA va a ser el camino más claro para el que quiera desarrollar una web 2.0 en un futuro.  </p><p class="P42">En resumen esta tesis concluye que el desarrollo de aplicaciones web 2.0 se puede realizar con SOA Open Source y que esta arquitectura ayuda al desarrollo, brindando facilidades para satisfacer requerimientos no funcionales complejos como por ejemplo la capacidad de escalar. Además nos brinda muchos beneficios técnicos como la facilidad de comunicación con otras webs. <span class="T53">  </span></p><p class="P43"> </p><h1 class="P55"><a name="Bibliograf_C3_ADa" />Bibliografía</h1><h3 class="Heading3"><a name="Libros_3A" />Libros:</h3><p class="P31"> </p><p class="P31">Open Source SOA.  </p><p class="P40">Autor: <span class="T63">Jeff Davis</span></p><p class="P40">Publicado por Manning Publications corp. </p><p class="P40">ISBN: 1933988541 </p><p class="P32"> </p><p class="P31">Java SOA cookbook </p><p class="P40">Autor: Eben Hewitt </p><p class="P40">Publicado por O’Reilly Media, Inc. </p><p class="P40">ISBN: 978-0-596-52072-4 </p><p class="P30"> </p><p class="P28">Service-Oriented Architecture: Concepts, Technology, and Design </p><p class="Textbody">Autor: Thomas Erl </p><p class="Textbody">Publicado por Prentice Hall PTR  </p><p class="Textbody">ISBN: 0-13-185858-0  </p><p class="P30"> </p><p class="P31">Service-Oriented Architecture Governance for the Services Driven Enterprise  </p><p class="Textbody">Autor: Eric E. Marks </p><p class="Textbody">Publicado por Wiley Publishing. </p><p class="Textbody">ISBN 978-0-470-17125-7 </p><p class="P30"> </p><p class="P34">Adopción de SOA para Dummies.  </p><p class="Textbody">Autores:Miko Matsumura, Bjoern Brauel y Jignesh Shah  </p><p class="Textbody">ISBN: 978-0-470-48334-3 </p><p class="Textbody">Publicado por Wiley Publishing. </p><p class="P30"> </p><p class="P31">Introducción a BPM para Dummies.  </p><p class="Textbody">Autores: Kiran Garimella, Michael Lees y Bruce Williams  </p><p class="Textbody">ISBN: 978-0-470-37359-0 </p><p class="Textbody">Publicado por Wiley Publishing. </p><p class="P30"> </p><h3 class="Heading3"><a name="Papers_3A" />Papers:</h3><p class="P30"> </p><p class="P28">Introducing SCA </p><p class="Textbody">autor: David Chappell </p><p class="Textbody"><span class="T43">Url: </span><a href="http://www.davidchappell.com/articles/introducing_sca.pdf">http://www.davidchappell.com/articles/introducing_sca.pdf</a></p><p class="Textbody"> </p><p class="P28">BPM and SOA </p><p class="Textbody">Autor: Mike Rosen </p><p class="Textbody"><span class="T43">Url:</span><a href="http://www.bptrends.com/publicationfiles/04-08-COL-BPMandSOA-OrchestrationorChoreography-%200804-Rosen%20v01%20_MR_final.doc.pdf">http://www.bptrends.com/publicationfiles/04-08-COL-BPMandSOA-OrchestrationorChoreography-%200804-Rosen%20v01%20_MR_final.doc.pdf</a></p><p class="P33"> </p><p class="P28">Oracle SCA – The Power of the Composite  </p><p class="Textbody">Autor: Pat Shepherd </p><p class="Textbody">Url: <a href="http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle-sca-the-power-of-the-composi-134500.pdf">http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle-sca-the-power-of-the-composi-134500.pdf</a></p><p class="P33"> </p><p class="P33"> </p><p class="P28">Fabric3 Reference  Guide</p><p class="Textbody">Url: <a href="http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf">http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf</a></p><p class="P27"> </p><h3 class="Heading3"><a name="Sitios_Web_3A" />Sitios Web:</h3><p class="Textbody"> </p><p class="P27"><a href="http://msdn.microsoft.com/webservices/">http://msdn.microsoft.com/webservices/</a> </p><p class="P27"><a href="http://complexevents.com/">http://complexevents.com/</a></p><p class="P27"><a href="http://www.soapatterns.org/">http://www.soapatterns.org</a></p><p class="P27"><a href="http://www.osoa.org/">http://www.osoa.org/</a></p><p class="P33"><a href="http://tuscany.apache.org/">http://tuscany.apache.org/</a></p><p class="P33"><a href="http://wso2.com/">http://wso2.com/</a></p><p class="P33"><a href="http://www.oasis-opencsa.org/">http://www.oasis-opencsa.org/</a></p><p class="P33"><a href="http://blogs.tecsisa.com/">http://blogs.tecsisa.com/</a></p><p class="P33"> </p><p class="P33"> </p></body></html>